Dirk Reiners wrote:
> 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?
>
>
Having OpenSG do it internally. My (possibly naive) approach would be
to scan a given plugin path and load all the .so/.dll files in that
directory. This would be similar to how other systems do it so I think
it could work.
>
>
>>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.
>
>
Is there any way possible we could still use Geometry::create(). I
guess this would really depend upon whether it is possible to compile an
application that uses the interface of Geometry without it having to
resolve the symbols at compile time.
As far as b), the method I was thinking of wouldn't need that (as far as
I can tell) because it would just load all the libraries that it can
find at startup time. There would be no dynamic searching of the
libraries that it needs for a given node type.
As an aside, using something like "FCFactory::create("Geometry")" would
not really help the usability of OpenSG IMHO.
>>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.
>
>
Agreed. I guess I was assuming that you or Gerrit could write a nice
magical macro call that would handle all the scaffolding. :)
-Allen
> 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
>
>
>
-------------------------------------------------------------------------
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
