"Dimitry Sibiryakov" <aafemt@...> wrote:

>
> 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 difference is that your proposal requires changes in other services that
are not related to the issue being solved.

> > 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?

Because utilities call the engine through the Y-valve. But utilities are
themselves contained inside the engine. So you get a chain:
client->Y-valve->engine->Y-valve->engine.

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

Nope. I mean that if utilities are placed inside the engine, then they
should *not* operate through the Y-valve. In my proposal, utilities are
outside the engine, so they can call it only via the Y-valve.


Dmitry