Roman and Jim,

>>It would be nice if Jim will react in this discussion, but unfortunately i'm afraid he doesn't :(
>>
> I'm here and paying attention. The discussion was going nicely and I
> didn't think it needed intervention.

I'm very glad to hear that.

> There is nothing wrong with a provider making calls back into the
> Y-valve through the proper, documented API provide that honors the
> "opaqueness" of handles. So both you and Roman are correct -- calls go
> only down the chain, but the dispatch modules can appear in the chain
> more than once. I trust that everyone understands that an infinite
> recursion isn't going to work very well.

Sounds logic and this will count already for the existing configuration.

> The dispatch module is indeed a provider for two reasons. First, it was
> the easiest way to build the beast. Second, my gut said it was the
> right way to do it. My gut has a pretty good but not perfect track record.

First i was a little bit confused by the abstract subsystem inherited everywhere, but after that it
shows a clear path through all nodes in the complete system.

> 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.

> But then we should stop calling Y-valve a dispatcher but
> rather a provider that is able to redirect calls to other providers
> according to some configuration if it decides so. Dispatcher somehow
> bears the karma of a simple/stupid router. :)

:)

Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database development support:
http://www.databasedevelopmentforum.com

Firebird open source database (based on IB-OE) with many SQL-99 features :
http://www.firebirdsql.org
http://www.firebirdsql.info
http://www.fingerbird.de/
http://www.comunidade-firebird.org/

Support list for Firebird and Interbase users :
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep :
news://newsgroups.firebirdsql.info