Subject Re: [Firebird-Architect] Vulcan services part II
Author Dimitry Sibiryakov
On 11 May 2006 at 9:37, Dmitry Yemanov wrote:

>We started from some issue (broken parts of SAPI in Vulcan) that
>requires some solution. The services provider + the proposed
>fb_engine_info() call solves the issue with little efforts, AFAIU.

Sorry, but I don't understand how proposed fb_engine_info() call
can solve the issue with _little_ efforts. It's interface is not much
differ from current services interface and it's implementation is
placed in Dispather - exactly where we suggest to place service
implementation with the same functionality.

>The alternative proposal complicates things much more. It requires an
>extention of the dispatcher interface and integration services into
>the engine.

Only part of services and only that part which is already served by
engine: backup, restore, gfix.

> Moreover, it will cause exactly that call loop which Roman
>would like to avoid, and even worse - the engine will be also called

When? Why? If the engine has refused to handle the request what the
purpose of calling it another time? To get the same answer?

> We'll just have the crap similar to what we have now with DSQL.

Do you mean this crap:

>Yeah, it requires call loops through the Y-valve, but it does fit
>the architecture and I see no issues with it.

> So what's the purpose, considering the particular
>Vulcan issue?

What's the purpose of this list at all?.. What's the purpose of
considering Vulcan at all? It's architecture is fixed and it does not
fit SAPI.

SY, Dimitry Sibiryakov.