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

Well... I have already expressed some time ago here in this list that
configuration might be ok on the server side, but not on the client,
at least not in the current form that requires text editor and some
experience to edit it. And I do believe that even server should work
fine even without configuration file.

But since configuration file was made the central point in our
architecture, I think we might also require it to be correct.

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

Now we have to convince the rest of the team that it does not bring
unneeded complexity, but instead simplifies the processing of the
requests on all layers.

Roman