On 24/05/2011 07:46, Alex Peshkoff wrote:
> On 05/23/11 16:27, Adriano dos Santos Fernandes wrote:
>> On 23/05/2011 09:21, Alex Peshkoff wrote:
>>> Yes of cause.
>>> I agree with all this words - but mentioned cache will anyway remain
>>> always empty in fbclient of FB3.
>>> And I do not say it must not be done - I say only that this is not top
>>> priority job.
>>>
>> Ok, but there is a design question. How the problem with unloaded
>> modules will be fixed.
>>
>> Also the current code received a function and does not base the cache
>> key on it, hence second code asking for it with a different function
>> will crash.
> OK, let's provide a plan. Certainly, function (or better vtable of a
> class containing it), used to upgrade interface must go into the cache key.
>
> There are 2 problematic cases here - one when a module which exported
> interface is unloaded, next is when a module which imported interface
> and therefore provided an upgrading class. When any of modules is
> unloaded, upgrade record should be removed from cache. At once notice
> that builtin modules (fbclient library and using it executable) do not
> affect removing records from cache.
>
> The best tag for a module is a pointer to IPluginModule, which must be
> created by each plugin module and registered using registerModule(). We
> can add getModule() function to IVersioned, which will be called by
> upgradeInterface() when adding record to the cache. What is a bit more
> problematic is how to pass calling module tag to upgradeInterface(). I
> do not want additional parameter - this is one of frequently called
> methods. May be replacing last parameter with
> class IUpgradeMethod
> {
> public:
> virtual void FB_CARG errorReturn(IStatus* s) = 0;
> virtual IPluginModule* FB_CARG getCallerTag() = 0;
> };
> is good way to go?
>
Not responding you directly, but anyway...
I'd want to say again that user should not pass a function to
upgradeInterface. Every function (except some ones from base-core
classes / IStatus) should consistently use a first parameter of type
IStatus. The upgradeInterface should point non-existent functions to a
function that set the status to not-implemented-error. A function passes
by the user is not only error-prone (as the code still needs to deal
with code saying not-implemented-error via status) but incorrect (you
can have a object pointing to only one vtable, while upgradeInterface
may be called by different places).
The more I see this the more I think a slight different solution should
be adopted. For example, we may have wrapper generated automatically,
and this vtable-changes may be done in the wrapper object vtable instead
of the wrapped one.
Adriano
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
