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 <[EMAIL PROTECTED]> 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 [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
