Hi,

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

For the fb_engine_info() method this is the idea.

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

No the fb_engine_info() call goes only into engines and not in the services provider.
The services provider calls fb_engine_info() to get the required information into the services provider. This is to
support backwards compatibility of the current service.

> If the services provider is a real provider, then IMO it should not have any
> knowledge of the installed engines.

It hasn't any idea of installed engines.

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

already there
...

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

My proposal

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

Yes.

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

That's something for the configuration, you must define which engines should be polled.
<engines generic>
provider remote engine11 engine8
</engines>

If multiple engines are defined every engine is polled and added to request, if you only add 1 engine this one is used
and only single version-info is returned.

As backwards-compatibilty step we could by default only return information about the first engine info block that's
returned. Than it will behave the same way as it FB2 and lower does. I don't see any problems here.

Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database developer support:
http://www.databasedevelopmentforum.com

Firebird open source database (based on IB-OE) with many SQL-99 features:
http://www.firebirdsql.org
http://www.firebirdsql.info

Support list for Interbase and Firebird users:
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep:
news://newsgroups.firebirdsql.info