|Subject||Re: Vulcan services engine info. was (engine information (nr. of attachments, da|
> The services module can call the in the Y-valve (Dispatcher) to askIt can't. Check all pictures from the Vulcan Architecture description.
> for engine information and the dispatcher will walk
> through all known providers and his subsystems to ask for
> information. This way the services module is able to handle
> return the needed information.
The call goes from upper layer to lower layer and response goes from
lower layer to the upper layer:
So, provider cannot call its dispatcher, otherwise the whole Vulcan
concept will be broken. We don't want this, do we?
> > Also traversing all providers cannot be done by another provider,Only when you declare dispatcher to be some kind of provider that can
> > but a component above those. So, I still believe that additional
> > API is needed to handle the "server-wide" requests.
> The dispatcher can do this.
handle some requests and forward others. But we need Jim to discuss
whether this is acceptable in his architecture or not.
> > As to my post about XML-RPC... Some time ago, if I rememberSure, we can't do anything without this method. But simply adding it
> > correctly,
> > Jim wanted to make all services available via the separate process
> > that would call either gbak or gfix (or any other command) and
> > translate their responses back in XML.
> IMO you'll remain with the problem how to get the information and
> that's why proposal to add fb_engine_info() to the
to the subsystem won't solve the issue how to collect information.
Until now dispatcher was a stupid router that mapped handles and
forwarded requests according to the configuration. But now we have to
add some logic.
> The Y-valve methods inherited also from the sub-system and thoseYes, but so far it had no true logic inside. Now dispatcher has to
> handles (dbHandle, svcHandle, reqHandle, blobHandle,
> ..) are internally mapped to the calling provider handles. For the
> engine-info call we don't have a (engine-) handle and
> i doubt if we need it.
look into the contents of the service call (SPB and SRB) and do some
additional processing (call all active providers instead of one and at
least sum all responses) and only then return response to the client.
And this is the place where we need Jim as an original creator of this
architecture - he has to tell us whether such extension is acceptable
or not, and if not - suggest a direction in which we have to dig.