|Subject||Re: Vulcan services engine info. was (engine information (nr. of attachments, da|
> > Second it. We don't need separate provider for service calls. TheNo, I think that either you're wrong here or you did not understand
> > 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.
the proposed change.
Dispatcher won't execute the backup call, but as before, route it to
the appropriate provider which will be determined from the SPB. The
only part that it will do itself are the calls that have to go to
multiple providers like fetching the number of attachments or the
isc_start_mutiple calls (the last one it handles already). The next
task is to map handles, this is done in dispatcher too.
The provider on the client side won't be able to do any backup or gfix
things - those are tasks for the engine providers. According to the
service manager name specified in the call (see example by Dmitry
Sibiryakov) it will determine that the service call goes to the remote
provider and forward it completely there.
If you have any local provider installed on the client side (engine8
for example) and the isc_attach_service will contain "service_mgr" as
the name, then dispatcher will forward the call to the local engine8
provider. But that is how it is supposed to work anyway.