Subject Re: [Firebird-Architect] Re: Vulcan services engine info. was (engine information (nr. of attachments, da
Author Arno Brinkman

>>I have no problem about looping through the active providers only. But
>>I see no problem about looping through all providers too - inactive
>>providers will provide empty reply that will not influence the overall
> I'm afraid this way Vulcan can become vulnerable to
> misconfiguration problems. What if some providers mentioned in config
> are missed?..

That's the case already? You can add provider that doesn't exists.

>>But now I have another question - why don't we move processing of the
>>Services API completely to the dispatcher and extend the subsystem
>>interface to execute database related service calls (like
>>backup/restore, gfix things, db properties, etc.)?
> Second it. We don't need separate provider for service calls. The
> idea is the same as with connections: Dispatcher either handle the
> request itself (for version, config or log request for example) or
> call every provider until one of them agree to fulfil the request
> (backup, gfix so on).

You'll give the dispatcher to much power and those are also on the client-side. It really doens't belong there.

>>In this case all what we talk here will get its logic and beauty - all
>>database specific calls are handled by the engine providers, calls
>>that span multiple databases/providers - by the dispatcher.
> Right layering. Jim should like it.

May be?

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: