Hi,

>> The services module can call the in the Y-valve (Dispatcher) to ask
>> for engine information and the dispatcher will walk
>> through all known providers and his subsystems to ask for
>> information. This way the services module is able to handle
>> return the needed information.
>
> It can't. Check all pictures from the Vulcan Architecture description.
> The call goes from upper layer to lower layer and response goes from
> lower layer to the upper layer:

> http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=vul_architecture
>
> So, provider cannot call its dispatcher, otherwise the whole Vulcan
> concept will be broken. We don't want this, do we?

The services module in fact already does. isc_compile_request, isc_receive, etc... are called in the
backup process.

>> > Also traversing all providers cannot be done by another provider,
>> > but a component above those. So, I still believe that additional
>> > API is needed to handle the "server-wide" requests.
>>
>> The dispatcher can do this.
>
> Only when you declare dispatcher to be some kind of provider that can
> handle some requests and forward others. But we need Jim to discuss
> whether this is acceptable in his architecture or not.

The dispather is a provider when we call a provider a module that inherits from the subsystem.

> Sure, we can't do anything without this method. But simply adding it
> to the subsystem won't solve the issue how to collect information.
> Until now dispatcher was a stupid router that mapped handles and
> forwarded requests according to the configuration. But now we have to
> add some logic.

Indeed the dispatcher will get the logic to combined the calls (which is pretty simple) from the
defined providers or only from the first one that succeeds depending on what we decide.

>> The Y-valve methods inherited also from the sub-system and those
>> handles (dbHandle, svcHandle, reqHandle, blobHandle,
>> ..) are internally mapped to the calling provider handles. For the
>> engine-info call we don't have a (engine-) handle and
>> i doubt if we need it.
>
> Yes, but so far it had no true logic inside. Now dispatcher has to
> look into the contents of the service call (SPB and SRB) and do some
> additional processing (call all active providers instead of one and at
> least sum all responses) and only then return response to the client.

If we decide that only the first one that succeeds will be valid it doesn't have to handle the
return-values itself.
When we decide to concatenate the results it's so easy as removing the last byte (isc_info_end) and
concatenate the next valid call. And at the end just add isc_info_end. I've also seen some kind of
logic in the dispatcher by the dsqlSqlInfo method.

> And this is the place where we need Jim as an original creator of this
> architecture - he has to tell us whether such extension is acceptable
> or not, and if not - suggest a direction in which we have to dig.

It would be nice if Jim will react in this discussion, but unfortunately i'm afraid he doesn't :(

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