Subject | Re: [Firebird-Architect] Re: Engine information (nr. of attachments, databases, db-name-info) for vulcan |
---|---|
Author | Arno Brinkman |
Post date | 2006-05-08T12:05:52Z |
Hi,
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.
information.
method.
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
> Each provider knows its open databases, right? It also knows theThis is how i understand it:
> corresponding accounts, right?
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 IPThis information is indeed only available at the server, but i was talking about engine information not about server
> 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).
information.
>> Providers don't have enough information for answerringThe engine providers will have enough information, but others don't and they just don't override the fb_engine_info
>> fb_engine_info() calls. Only server has. But even server can be
>> wrong (consider Classic mode for example).
method.
> I agree with you (and have written that in my post) that providerI'm really missing your point here, the current services modulel seems to be what you describe.
> 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.
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