Hi,

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

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