On 10 May 2006 at 8:13, Roman Rokytskyy wrote:

>> Who can answer about list of active databases I don't know.
>> Probable, all active providers and dispatchers in stack.
>
>Remote provider handles only wire protocol.

Right, and it'll send the request through the wire without further
thinking, receive the answer (whatever it is) and return it to
dispatcher.

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

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

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

--
SY, Dimitry Sibiryakov.