> Dispatch doesn't know the difference between an engine, a remote
> interface, a services module, or a gateway. Furthermore, it
> shouldn't.

True and so should it remain. The Dispatcher uses configuration to
determine the provider the same way you do this for the databases,
only that we need one more entry

<service service_mgr>
provider engine11 engine8
</service>

<service *:service_mgr>
provider remote8
</service>

The first entry will provide a list of local providers to which
Dispatcher can talk to, the second entry provides a way to handle
attachments to the remote service calls.

> Does it really make sense for dispatch to call other providers? How
> is the service supposed to work remotely, for example? The remote
> interface doesn't keep statistics, and without a context, can hardly
> forward a request.

The remote interface come in play only if on service attachment the
host name was specified. In our current world services provider can
either collect data from local providers or from the remote provider,
but not from both.

> Even with aggregation in dispatch, getting any meaningful
> information that way is tough, particularly if rigorous security is
> imposed. Maybe you would be happier just asking whatever provider
> you're connected to and leaving it at that.
> ...
> Sorry, that wasn't my idea. Since the dispatch module doesn't know
> what a services provider is, it is going to be difficult to
> implement. Maybe worse, it would require taking to a provider
> without first establishing an attachment with credentials validation
> with either create or attach.

But we are not connected to some specific provider, are we? With each
call we pass a piece of information that allows dispatcher to
determine the provider to which the information is forwarded to.

As to the security, the "number of attachments" call at present time
has to go without authentication anyway, since there is no database
from which we can determine what security database to use...

We should add default security database for provider-specific calls:

<provider engine8>
library engine8.so
SecurityDatabase security.fdb
</provider>

<provider engine11>
library engine11.so
SecurityDatabase security2.fdb
</provider>

This would however require that admin creates the same account in
security.fdb and security2.fdb. But I guess we can't avoit it, can we?

Roman