Re: [boost] extensions/plugins library, conclusion

From: Jeremy Pack (jeremy.pack_at_[hidden])
Date: 2006-10-09 18:04:01

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_at_[hidden]> wrote in message 
news:20061009204414.617b8de7_at_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
>