I'm just rushing through my mountain of email so a quick reply is the best I can do right now.
The first thing ideal that popped into my head is that if you want your plugins to easy to use, cross platform and version robust then perhaps C or C++ is the wrong language. Python or Lua might well be the ideal language to this type of work.
Robert.
On 10/9/06, Chris Hanson <[EMAIL PROTECTED]> wrote:
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/
