"Roman Rokytskyy" <rrokytskyy@...> wrote:

>
> My idea was that client Y-valve loops through all affected providers
> below it and collects the responses. If no server was specified in the
> call, it will check only engine providers, if server is specified in
> the call, it will send request only to remote provider. This remote
> provider sends request through the wire, server handles it and simply
> forwards to another Y-valve. That Y-valve loops through all local
> providers, collects responses and sends them back.

So far I tend to support this approach.

> Arno and Jim suggest different thing. The idea is that Y-valve
> delegates the info request to services provider, which has the list of
> local engines and this services provider calls the same Y-valve again
> specifying to which provider request should be forwarded.

If the services provider is a real provider, then IMO it should not have any
knowledge of the installed engines. And even if it does, how should it
specify a particular provider to process the call? Does the Y-valve support
this stuff? Perhaps via some config trickery? If so, the Y-valve becomes not
so dumb as we expect it to be. Well, the same goes for the former approach,
but it looks more layering friendly to me than the latter one.

But let me present my thoughts a bit wider (sorry for repeating the things
already mentioned). I have no objections to Services API being implemented
as a separate provider. It's a server-wide API, so IMO its features belong
outside the engine provider. The services provider may decode SPB and then
launch utilities via threads or processes, those utilities will then call
the Y-valve and so on. It can also return the log file contents, provide a
configuration management, etc. So far everything fits the architecture. The
only feature that doesn't is the information requests that started this
discussion. In order to process those requests, the services provider should
poll all engine providers. But as it's outside its layering abilities, it
should delegate the call to the Y-valve which can perform such a polling. So
the scheme looks like:

isc_service_start, backup (Y-valve)
|- SPB processing code (services provider)
|- gbak
|- isc_attach_database (Y-valve)
|- attachment processing code (engine provider)
...
isc_service_start, number of attachments (Y-valve)
|- SPB processing code (services provider)
|- fb_engine_info (Y-valve)
|- engine info code (engine provider 1)
|- engine info code (engine provider 2)
...

The above means the compatibility mode, i.e. usage of the Services API.
Alternatively, one could use fb_engine_info() directly from the client side.

Do I understand the things correctly?

But there's one issue here (it has alredy been mentioned as well). Some
information requests require a subsystem poll. Those are enumeration of
databases/attachments/users. But there are other calls that require to call
only one subsystem. A version information is a good example. Now imagine
that SPB contains mixed enumeration and version requests, so both goes into
fb_engine_info(). Should the Y-valve parse its input buffer and process
requests differently? IMHO, it looks pretty outside its intelligence. But
otherwise we'll get version info from all engine providers and I doubt this
is what users expect to see.


Dmitry