Janek and Robert (and others), First of all, the library that I'm working on does use the Serialization library, but not to the level that Robert is suggesting. Two points: 1 - The exporting of classes from a dll or whatever is not a terribly difficult part to implement - if this were all that I needed, I would not have started my own library. However, I agree that this part SHOULD use boost::serialization (not reusing already proven code would be a mistake in this case). As long as the way that has been suggested will meet a few criteria, I think work should immediately begin on doing it using Robert's suggestion. I will check through the extended_type_info documentation to see if it will be able to provide each of the requirements that I feel necessary. It sounds like it does. 2 - The primary requirement that is important to me is tracking dependencies between loadable objects. I'm working on a relatively flexible way of handling that. I think it is a vital part of making this library more useful than just a classloader. It's also, I think, the hardest and most subjective part. I will still attempt to get my code posted, keeping in mind that most of the object loading will probably be completely rewritten to use extended_type_info. Robert, if you have the time, I believe your experience creating the boost::serialization library would make you the most qualified to head up the effort to create a plugin library for Boost. Even if you don't have that kind of time, your continuing input would be very appreciated. Either way, hopefully my code could be a good launching point for this. I hope to have it posted in a few days. One important question: should we avoid requiring RTTI? Should boost::serialization make it unnecessary? I'm currently using a dynamic cast or two, mostly just for type safety. I know that certain older compilers have a problem with that (Borland at one time, perhaps still, cannot handle RTTI in DLLs correctly for instance), and it might annoy people to have to remember to enable it on those that do not. Thanks again for all of the input. Jeremy Pack "Janek Kozicki" <janek_listy@wp.pl> wrote in message news:20061009204414.617b8de7@absurd...
Robert Ramey said: (by the date of Mon, 9 Oct 2006 09:31:38 -0700)
Janek Kozicki wrote:
Think of it. With two separate libraries (one for serialization and one for plugins) the user will have to register each class twice. Serialization already registers classes with GUID (Global Unique IDentifier) so plugins/extensions library should take advantage of that.
Oh no. registering a data type for export would be sufficient for plug-ins AND serialization.
Yes you are right. Slight misunderstanding here. I was talking about "two separate, totally different" libraries. Like we already have boost::serialization and a new library from Jeremy that doesn't know or use the mechanisms from serialization but instead reinvents the whell. And I meant that this would be bad.
So I would like to see:
a) a plug-in library based on ehancement of extended_type_info b) serialization tweaked to use this library.
Then we get a "smaller" serialization library - and a separate self contained library which is useful for other things. Just a little code re-factoring.
yes, I agree 100%
So if we start working on this, we simply continue the work started by introducing extended_type_info
But since it's Jeremy who started this thread I await his (your ;) acknowledgement of this conclusion. I'll try to help in doing that (as usual - given enough time...)
-- Janek Kozicki | _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost