Subject Re: [Firebird-Architect] Re: Engine information (nr. of attachments, databases, db-name-info) for vulcan
Author Arno Brinkman

> Each provider knows its open databases, right? It also knows the
> corresponding accounts, right?

This is how i understand it:

A provider isn't necessary a engine, it can also be remote or services.
They all inherited from a subsystem where abstract methods are defined.
Every provider overrides the method it can support.

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

This information is indeed only available at the server, but i was talking about engine information not about server

>> 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 engine providers will have enough information, but others don't and they just don't override the fb_engine_info

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

I'm really missing your point here, the current services modulel seems to be what you describe.

Arno Brinkman

General database developer support:

Firebird open source database (based on IB-OE) with many SQL-99 features:

Support list for Interbase and Firebird users:

Nederlandse firebird nieuwsgroep: