Subject Re: [Firebird-Architect] Vulcan services part II
Author Arno Brinkman

> But that is how all services work since IB times, according to initial
> design. And I don't think it's a good idea to fix one, leaving all the
> rest "as is". We have at least one more serious problem with services
> design: badly designed (to be more precise - illegally designed) formats
> in SPB. To decide, where particular clumplet ends, it's not enough to
> take into account it's tag (even this is not needed in DPB), one must
> take into account previous clumplets in that SPB. And if we plan to add
> new version of services manager, it will be good idea to fix all known
> problems in services, not only some of them. Moreover, not to fix only
> one specific service.

Ok, i agree that the way service actions are called could need a complete review, but this isn't the
time for it. This is something for FB3+ (or when someone would spend time on it after vulcan
release, FB3)

We come back to the solution that the engine needs to provide his information. So i go on with the
fb_engine_info() method and won't add support in the remote layer, but to leave this possibility
open to support it in the fb_engine_info() method.

Arno Brinkman

General database development support:

Firebird open source database (based on IB-OE) with many SQL-99 features :

Support list for Firebird and Interbase users :

Nederlandse firebird nieuwsgroep :