Re: [boost] [serialization] extended_type_info asextensions/plugins library ?

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-10-09 12:44:06

Martin Bonner wrote:
>> From Janek Kozicki:
>> So I think that this should be the goal to pursue if we want to add
>> an extensions/plugin library into boost.
>>
>> 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.
>
> I'm not convinced.  It seems to me that the registration for plugins
> and for serialization is rather different.
>
> Serialization:
> - When you see this GUID, this is how to create the class.
>
> Plugins:
> - This is another object with an IFoo interface.

Almost but not quite.  This is another object with an IFo interface.
But which object.  There can be many different types.  So each
type is identified by a GUID - same one used by the serialization
system.  So the magic missing function is

BOOST_CLASS_EXPORT(IFoo_derived_1, IFOO_ONE)

IFoo *ifptr = static_cast<IFoo 
*>(extended_type_info::create_object(IFOO_ONE))

This is basically how microsoft COM works.  This system would be
simple, fast, powerful and easy to implement.  It would be upto
the programmer to ensure that the static_cast is correct.

> Perhaps I'm misunderstanding what you mean by plugin, but I think of
> something like Internet Explorer, or Photoshop, where the application
> has a bunch of IFoo pointers, and it iterates through all of them to
> extend its menu.  When the menu is clicked it calls the appropriate
> function through the IFoo pointer.

This is exactly the case that I have in mind.

> I don't really see how the two relate.

Hopefull the above will clarify this.

RObert Ramey