Re: [boost] [SoC] Interest of a plugin library

From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2007-03-13 20:36:57

On 3/13/07, Robert Ramey <ramey_at_[hidden]> wrote:
>
> I've looked at this proposal a little bit.  I was expecially curious how
> it managed to do this totally within a header with not static objects.
> I had been unable to do this.

It took me a while to figure out. I probably wouldn't have submitted the
library without this feature - it is one of the primary features that sets
it apart from the other plugin libraries that I was able to find.

Looking at a tiny bit more carefully, it seems to be that it presumes
> that the possible "plug-ins" are listed ahead of time.  I'm not sure
> what the all the implications of that are.  But it would preclude
> shipping an add-on DLL to be used by an existing program.

I can see how my examples might give that impression. It does NOT require
that the plugins be listed ahead of time. It does require that some sort of
interface (base class) be defined ahead of time. But shipping an add-on dll
to be used by an existing program is the primary goal of the library.

I think one of my examples shows that pretty well - look in the examples
folder for the hello world example. The "existing program" (main.cpp with a
header of word.hpp) only knows about the word class. The "Add-on DLL"
(hello_world.cpp, which also uses word.hpp) is the only entity that knows
about the hello and world classes. But the "existing program" can use them,
because they are both derived from the word class.

I will attempt to have decent documentation up with the rest of the code
very soon. Thanks to all of you who have taken the time to look through the
library anyway!

This isn't necessarily a criticism, but its clear to me that this is
> a "different thing" than what is part of the serialization libary.
>
> The extended_type_info component could use a "construct
> from id" function.  The serialization library doesn't need it
> but I thought it make make the component more useful.
> The details turned out to be problematic.  But recently
> a possible way to do this has occurred to me.  So maybe
> something will happen someday in this regard.
>
> Implementing this for non-RTTI wasn't all that hard
> as I remember.  It did require a fair amount of
> code shuffling which resulted in breaking out extended_type_info
> as a separate component.
>
> The current version depends upon static objects to
> register themselves in a global table so they don't have
> to be "pre-registered" by the programmer.  This is
> convenient - and its what people insisted on - but I think
> this is the root cause of some of difficulties which
> occured (hopefully resolved in the HEAD) with
> the dynamic loading/unloading of DLLS.

That is what I expected - I doubt that there is a way to do the extended
type info without static objects unless you require a bit of extra work from
the user.

The serialization library lets one select the typeinfo
> system he want's a particular class to use.  The common
> one is RTTI.  However, one based on the specified
> EXPORT name is also implemented.  There is a test
> which demonstrates that the different systems
> inter-operate.  So it might be interesting to see
> if this method would/could be used as another
> variation of extended type info.

This would be very useful for plugins - allowing a choice between the
systems would definitely alleviate a lot of people's concerns.

I didn't spend a huge amount of time looking at it
> so feel free to take these comments with a grain of salt.
>
> Robert Ramey

I don't expect anyone to take a huge amount of time looking at it yet - I
put it up to find out if anyone had suggestions for API improvements or
additional features. Thanks for looking over it!

Jeremy Pack