Hi Allen,

(I'll answer to the big mail later. Big mail answers take a little more
time. ;)

On Thu, 2006-08-17 at 17:08 -0500, Allen Bierbaum wrote:
> We were sitting around talking today before lunch about OpenSG 2.0 and 
> the split to use a larger number of small libraries to help link speed.  
> One of the problems that this causes is that applications need to know 
> more libraries to link against.  As we talked more we started wondering 
> whether it may be possible to use the plugin mechanisms in OpenSG to 
> dynamically load the libraries. 

Are you thinking about OpenSG doing that internally or via the OS's
dll/so dependencies?

> Dirk has told me that this should be able to work for image loaders and 
> could help with some build issues related to dependencies.  

My main goal was to have a way to to be able to build a version that has
all the bells and whistles compiled in, but only supports the ones that
are actually installed on the system without totally losing it (as
happens right now if one of the dependencies is not installed).

> But we 
> started wondering, couldn't you also dynamically load all the node 
> cores?  For example have a library for all the Drawables and another 
> library with all the Groups and so on.  Then we would get the best of 
> both worlds.  There would be small link times when compiling OpenSG and 
> applications would still only need to link against a few libraries 
> (Base, System, GLUT).  Everything else would be loaded dynamically.

I've been thinking about that, and I think it would be very possible,
under two conditions: a) the dynamic type resolution is used for all
object creation (i.e. no Geometry::create() any more, but
FCFactory::create("Geometry") instead), and b) the system would need to
have a way to identify the library that contains the FC; my suggestion
would be to expand the namespace of FCs to include the library name
(e.g. use "System::Geometry" instead of "Geometry"). b) shouldn't be  a
problem on the road to 2, a) might take more convincing.

> As an added bonus this would show users how they can extend OpenSG by 
> adding new cores and other fc's without compiling it into the library.  
> Just create your own core, dump it in a directory, and it magically 
> works.  Sounds interesting to me.  Is it possible?

Well, it won't be quite that easy, as the so needs to have some
provisions to register itself correctly when loaded, so there will still
be some scaffolding needed. But you're right, it would create a whole
bunch of nice examples for people to start with.

        Dirk



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to