Subject Re: [Firebird-Architect] Vulcan services part II
Author Arno Brinkman

>>1) Increase subsytem with more calls, so engine can support
>> Dispatcher should handle the service params and implement services.
> Note: not all services but only those that cannot be served by
> providers.

I think that are a lot.

>>2) Increase subsystem with fb_engine_info() method only.
>>fb_engine_info() has dbHandle so dispatcher can lookup provider.
> For this purpose we already have isc_database_info() which has
> dbHandle.

Yes, a somewhat equal call, but database_info returns only information about the specified database.
fb_engine_info returns information over all active databases.

>>3) Increase subsystem with fb_engine_info() method only.
>>fb_engine_info() has nodePath (string) which for example holds
>>servername(s) (and engine name?).
> For this purpose we already have isc_service_attach() which has
> "service" param that holds servername (and engine name?).

But it attaches to a services provider and not engine.

>>I think 1 will make dispatcher to complex, because it has to implement
>>a service which needs to do many things (think about quering running
>>progress etc..).
> Not so complex because all things you are thinking about must be
> served not in dispatcher but in providers. Dispatcher is for global
> things only.

That's what currently is already the situation. The only missing thing is the engine information, that what we're
discussing about?

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: