On 11 May 2006 at 11:43, Dmitry Yemanov wrote:

>But not about databases or users. The info requests cannot be handled
>only by the Y-valve.

Right. These requests can be handled only by all providers
together.

> Also, AFAIK the Y-valve has no idea whether it
>runs on the client side or on the server. But the client side itself
>cannot process your request while the server one could. So the Y-valve
>*must* delegate the call to some provider.

But there is no difference between client Y-valve and server one.
The difference is in config and providers' set.
If I address my request to local Y-valve, it may return information
or not, depending (again) on config and set of installed providers.

>> But it should implement fb_engine_info() call which has no
>> considerable differences from SAPI.
>
>It's dumber, as it should not make any decisions itself.

Why? It must walk all providers and collect information. I can't
see the need for additional trip into services provider and back.

>> Do you mean that fb_engine_info() can be called from remote site?
>
>It depends on how we design the things. I don't want to see the host
>name passed to fb_engine_info() as it duplicates SAPI.

This call duplicates SAPI in any case. There is no difference
between receiving "service_mgr" in parameter or don't receiving
parameters at all.

--
SY, Dimitry Sibiryakov.