All,

We started from some issue (broken parts of SAPI in Vulcan) that requires
some solution. The services provider + the proposed fb_engine_info() call
solves the issue with little efforts, AFAIU. Yeah, it requires call loops
through the Y-valve, but it does fit the architecture and I see no issues
with it.

The alternative proposal complicates things much more. It requires an
extention of the dispatcher interface and integration services into the
engine. Moreover, it will cause exactly that call loop which Roman would
like to avoid, and even worse - the engine will be also called twice. We'll
just have the crap similar to what we have now with DSQL. I agree that the
utitilies can be layered properly and integrated deep inside the engine, but
IMO it will cause some code divorse as their standalone counterparts will
still be bound to the Y-valve. And anyway, proper layering of the utilities
(provided that we'd agree, which is not the case yet) is *not* going to
happen in either v3.0 or v4.0, believe me. So what's the purpose,
considering the particular Vulcan issue?


Dmitry