Hi,

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

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