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
>twice.

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.