"COM/ActiveX is out for many reasons." Why? My undertanding is that the basis of COM is a C structure, I would have thought it met your design requirement. I have implemented a couple of components where the structure was more a C++ rather C style structure.
The only essential entry point in a Windows DLL to support COM is a factory method. Others can be added to marshall data etc, but really only the factory method (function) needs to exist. In designing the interface, fewer methods is good. When you look inside a DLL with the VS depends.exe, it is very weird just finding a single factory method. There are no issues debugging COM code, and minimal (or zero) time penalties once an interface has been created by the factory. The advantage of COM is runtime linking - no need to distribute lib files - just an include file to describe the interfaces returned by the factory method and the actual DLL. Of course, you would have issues with non Windows OS ...... COM is not nirvana or perfect, but it is simple. The best short coming is the lack of smart pointer handling when creating copies of interfaces. COM has been superseded by COM+, but its still worth a look. Alternatively look at how OSG handles its plugins. Regards -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Chris Hanson Sent: 09 October 2006 22:44 To: osg users Subject: [osg-users] Semi-OT: Plugin architectures This is not directly an OSG, issue, but I'm guessing many OSG users have faced this same issue, and OSG itself faces it and chooses not to address it. ;) I'm in a situation where I have a small external API for one of my programs, implemented with VERY basic C-flavor DLLs. I'm not crazy about this approach, and I'm looking for something better before getting locked into backward compatibility with an inferior design. I'd like to have a component/plugin system that has several qualities: Workable on multiple OSes Currently maintained (or at least, not abandoned) Has some decent concept of an object, data members and methods I'd be ok with data member access being implemented only through set/get ops Doesn't require a 12-month indoctrination in toolkit philosophy Build system understandable by mere mortal programmers Supports application calling plugin methods Supports plugin requesting services from application Supports multiple versions of a method for API evolution Supports variable args to methods OSG takes the easy route of using straight C++ object linkage, which is highly transparent and powerful, but breaks version linkage every time the slightest thing changes in the class definitions, and requires _exactly_ the same compiler in use on both sides of the API. Which is fine for OSG's requirements. I'd like to ensure that people could write plugins for my program in VC++6 or 7 or 8 or GCC or anything reasonable and use them with my VC++8 application. So, that pretty much means C-linkage only (no STL or stdio exchange across the API barrier). COM/ActiveX is out for many reasons. Here are some of the resources I've looked at, from full systems to just simple programming techniques. http://www.newty.de/fpt/index.html http://sourceforge.net/forum/forum.php?forum_id=370728 http://www.mozilla.org/projects/xpcom/ For those who came from "that side", I'm thinking a little bit of the Amiga TagLists http://fredrik.rambris.com/libtaglist/ they sort of solve the same set of problems -- making a flexible API (between the application and the OS in the Amiga's case) that could sort of grow and evolve. That was all C-based. My users would like to work in something that kind of looks like C++, I'm thinking maybe the underlying mechanism could be this non-object-oriented taglists and I could make a dummy framework object on top of it on the plugin side that made it look like you were talking to the system via an object. I don't think I'm specifically asking for reflection or anything as heavy as SWIG. Mostly I'm looking for advice or suggestions from others who may have gone this route. I'm sure others will follow in the future and maybe can benefit from the answers to this question. -- Chris 'Xenon' Hanson aka Eric Hammil | http://www.3DNature.com/ eric at logrus "I set the wheels in motion, turn up all the machines, activate the programs, and run behind the scenes. I set the clouds in motion, turn up light and sound, activate the window, and watch the world go 'round." -Prime Mover, Rush. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
