How Else to Interact with Browser (wasRe:RevolutionWebBrowserPlugin)
chris bohnert
chris at altuit.com
Mon Nov 6 16:12:49 EST 2006
I think Dar illuminates some of the technical and strategic problems that
Rev faces in trying to create this new layer of "openness" without just
opening the code completely.
What model to adopt? COM+IDL(for the windows guys in the house),nsCom(for
the mozilla fans),Kparts(if you luv some KDE),or Orbit or one of the other
CORBA variants for the gnome guys. The point? If Rev simply adopted one of
the existing mechanisms they would have to deal with a technical boat load
of leaky abstractions that might pop up in a cross platform environment not
to mention the possible strategic blunder of alienating fans of the
non-implemented solution.
Don't get me wrong. I'm definitely in the "me too" club on a new externals
interface. I just the the cart is still well in front of the horse on this
one.
--
cb
On 11/6/06, Dar Scott <dsc at swcp.com> wrote:
>
>
> On Nov 6, 2006, at 1:08 PM, Andre Garzia wrote:
>
> > I completely agree with you on that one, we need a new foreign
> > function interface so that skilled developers can write interfaces
> > with existant c code, or frameworks or com objects or whatever in
> > an easy sane way.
>
> I created an interface for DLLs including system DLLs (almost ready
> for PPC frameworks). I tried to make it tolerant, requiring only a
> minimum of knowledge of C types, close to xTalk as I could. I
> failed. I sent a simple version (C structs) to "alpha" testers. The
> response from alpha testers was completely underwhelming. (This
> robustly handled several calling methods, but did not include C++
> names.)
>
> Perhaps COM+IDL or Automation would be an easier level for
> Revolutionaries. With those, the user (or techy friend of user)
> would not need to define the functions. It might be possible to
> unmunge some C++ names and infer function types from that.
>
> Perhaps the "skilled developer" who can use such an interface is the
> same one who can build externals. For most externals, I now use a
> simplified proto-SDK that makes building externals easier and I hope
> safer; maybe we need more of that. Also, I think the Externals SDK
> now comes with a helper stack for starting projects. (I had already
> started tinkering with my method so I haven't explored that.)
>
> Perhaps I need a broader base of early examiners or I didn't support
> them right.
>
> I've been thinking of a simple variation that would create Rev
> interface commands and functions. Maybe that would be easier. It
> might also be faster.
>
> Another alternative might be a tool where one can quickly go though a
> DLL or Framework document and make Rev friendly interfaces and
> document those. This might handle COM when an IDL file is available
> or even Automation.
>
> It would be nice to have an enhanced external interface, though.
>
> Dar
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
More information about the use-livecode
mailing list