Vlad Khorsun escreveu:

>> Plugin is object constructed and destructed by FB. It can't receive
>> notifications on destructor.
>>
>
> User library implements factory which creates some user-defined object. This
> object have constructor, destructor (or its equivalents) and able to use
> fb_shutdown_callback. Is it clean now ?
>

It seems we lost again. You asked if all plugins should use factories
and I said no, with a "listener" (instead of factory) example that come
to my mind. I'm not proposing it or discussing if it's better than
fb_shutdown_callback.

>> I see no advantage. Just some class/method rename and inability to have
>> non-factories plugins.
>>
>
> It not forced us to introduce methods in PluginManager for every new plugin
> kind supported by the engine. I think its good and correct approach. Also i see
> no sence to introduce PluginFactory interface and allow to not use it. And i see
> important task to name things correctly

I disagree. The (internal) PluginManager should understand "kind" of
plugins. It's it that offer plugins to FB engine. And different kind of
plugins may use different (factory is not good for all) interfaces.

> - generic plugin API must be separate
> from all other XXX API's.
>

And it introduces enumeration and abstract factory without a way to
check in passed object is from correct implementation. It also introduce
need of casts in the engine.

>
>>>>> So, you offer to declare as many REPLICATE triggers as destination datasources
>>>>> and mark each of them by corresponding datasource name in <misc info> ? I don't
>>>>> think its OK. Instead i would put all destinations names into separate table and
>>>>> read this table in one REPLICATE trigger.
>>>>>
>> No. Example was with one trigger per table. It just encode info
>> necessary to the trigger work in the entrypoint.
>>
>
> Imagine i have N destinations. How must i change your trigger example, to
> replicate to the all of them ?
>

Redesign the example to fit your needs. ;-)

>
>> Otherwise a new table
>> should be created mapping trigger metadata names to misc info.
>>
>
> And remove <misc info> from trigger declaration ?

It's optional clause not interpreted by lower layers. You could do what
you want.


Adriano