> But there's one issue here (it has alredy been mentioned as well).
> Some information requests require a subsystem poll. Those are
> enumeration of databases/attachments/users. But there are other calls
> that require to call only one subsystem. A version information is a
> good example. Now imagine that SPB contains mixed enumeration and
> version requests, so both goes into fb_engine_info(). Should the
> Y-valve parse its input buffer and process requests differently? IMHO,
> it looks pretty outside its intelligence. But otherwise we'll get
> version info from all engine providers and I doubt this is what users
> expect to see.

No, the solution to this problem was already presented. The original
fb_engine_info() call goes directly into the services provider. The
services provider splits the parts of the requests and processes them
separately.

When it meets the isc_spb_num_att, it looks up the configuration, gets
the list of the engines and calls the Y-valve few times with the SPB
that includes both isc_spb_num_att and
isc_spb_require_engine="engine8" for example.

The dispatcher sees that SPB contains isc_spb_require_engine="engine8"
and sends request only to the engine8 provider.

If the original SPB also contained isc_info_svc_version, this part of
th erequest is processed as usual.

Results of the processing of different parts of the request are
combined into the final response and returned back to Y-valve.

But I am more and more convinced that the whole concept of a provider
calling the Y-valve while processing the request that same through
that very Y-valve is bad and in the future it will produce more
problems than solve.

Roman