> > Consider the situation when we have engine8 and engine11 providers
> > and single services provider (a bit nonsense, but good for this
> > example). How could the callback work, to which provider would
> > dispatcher redirect the request - engine8 or engine11? The
> > configuration should somehow specify that callback from services8
> > should go to engine8 and from services11 to engine11... I have not
> > seen such thing in the Vulcan so far.
>
> Services isn't called services11 or service8 currently, but i get
> your point. The running service will call the dispatcher for
> fb_engine_info() and get information back from the
> engines configured in the config file.
> <engines>
> provider engine11 engine8
> </engines>
>
> The engine (or any provider) is the only one who knows who he is.
>
> A way to handle this:
> Because we send request items to the fb_engine_info() method we can
> add an info request item "isc_info_engine_req_match". This request
> item will be followed by an string. When the string matches it
> returns the information requested else it doesn't give any
> information about the engine. If no "isc_info_engine_req_match" is
> added all requested information for every engine is returned.

Ok, this will work.

But I have to say that letting services provider to know the names of
the other providers on the same level and let it specify which of them
has to process next request passed through sounds not very correct.

It looks that we are loosing the idea that Y-valve provides necessary
opaqueness to the way requests are processed - only Y-valve knows
where to forward them. If that were classes hierarchy, I would say
that it has quite high cohesion. Later this might make the refactoring
harder. In our case adding a new provider in one place of the config
file will require it to be added to the <engines/> section too. But I
guess we have to allow this evil to make current Services API work.

Roman