--- In Firebird-Architect@yahoogroups.com, "Dimitry Sibiryakov"
<aafemt@...> wrote:

>
> On 6 May 2006 at 21:59, Roman Rokytskyy wrote:
>
> >> We could have multiple engines, so we need to walk through all known
> >> providers and subsystems. For every subsystem from the provider the
> >> fb_engine_info() function is called. As far as i understand the
> >> Dispatcher it the place to handle this.
> >>
> >> Ideas, suggestions, comments?
> >
> >I think we have two problems here.
>
> I think there is third problem here: where providers can get
> requested information from?
> I mean: Dispatcher has loaded a provider and ask it "how many
> users are connected to you"? What should the provide do?
> a) Should it keep list of connections in some kind of internal
> provider-global cache? No! Too ugly.
> b) Should it onestly answer "I don't know"? No. It is useless.
> c) ???

Each provider knows its open databases, right? It also knows the
corresponding accounts, right? What it does not know is the IP
addresses of the connected clients, this information is available one
layer above, however if needed, it can be derived using a correlation
ID (db handle + provider ID).

> Providers don't have enough information for answerring
> fb_engine_info() calls. Only server has. But even server can be
> wrong (consider Classic mode for example).

The Classic mode is not very good example, since the fb_inet_server or
inetd are not interested in answering any question - they simply map
data streams.

I agree with you (and have written that in my post) that provider
cannot answer all the questions, only server can. Therefore we need a
mechanism to handle server-wide requests, something similar to our
current Services API, which conceptually is a server-wide API, not the
database-wide. That should be completely different API, not the one
that is used to communicate with the provider, it might be similar to
our current Services API (C calls with some parameter buffers and info
structs) or it can be fully XML-based with nice XML-RPC-over-HTTP
interface.

Also, since server can handle only those requests it was programmed to
handle, I suggested to provide a mechanism to collect information from
all active providers in a unified way. In this case the info request
will be passed sequentially to each provider and will be delivered in
"raw" form to the client.

Exactly this mechanism is supposed to be used by the new API to handle
those server-wide requests (e.g. number of attachments, account names,
etc). Obtained information should be combined with the one available
on the server-layer and this combined info will be delivered to the
client.

Roman

P.S. I'm not yet sure with the interface on provider side. It might be
that we should only provide a possibility to execute some query
against upcoming monitoring tables in all providers and combine the
information from them...