On 10 May 2006 at 5:58, Roman Rokytskyy wrote:

>> And it doesn't (directly). Remote provide simply sends request
>> through the wire. It is just an coincidence that on the other and of
>> the wire another Dispatcher is sitting and handling these requests.
>>
>> >So, unless you make dispatcher to be some kind of provider that can
>> >handle some requests and delegate others, you can't solve this without
>> >breaking the layering.
>>
>> I can. There is no breaking if these Dispatchers are different.
>
>Sorry, I am confused now. Which provider is going to handle the info
>call request?

All, including Dispatcher. Actually, it depends on what kind of
information is requested.
For example, configuration information belongs to Dispatcher only
and other providers can't say anything useful.
Who can answer about list of active databases I don't know.
Probable, all active providers and dispatchers in stack.

>My idea was that client Y-valve loops through all affected providers
>below it and collects the responses.
>
>If that is what you are talking about, then we were talking about the
>same thing all the time. But this also means that Y-valve is handling
>some requests (our info call) itself and the rest of the calls
>delegates to the underlying provider (engine or remote).

Yes, this is what we both are talking about. But I suggest to loop
only through active providers while you are (AFAIU) going to use all
providers known to dispatcher (mentioned in config?).
And yes, dispatcher must be not as dumb as Jim would like it to be.
It must keep some information (what it already does) and handle some
requests itself (as it also already does - fb_start_mupltiple() for
example).

>Arno and Jim suggest different thing. The idea is that Y-valve
>delegates the info request to services provider, which has the list of
>local engines and this services provider calls the same Y-valve again
>specifying to which provider request should be forwarded. After
>calling all specified engines, services provider processes the
>responses and returns the reply back to the Y-valve, which in turn
>returns it to the user.

IMHO, this is a bad idea. We don't need another Dispatcher and
especially hacks like this. DSQL in FB is made using the same
technique and anybody can say anything good about it?..

--
SY, Dimitry Sibiryakov.