Arno Brinkman wrote:

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

Yes, fb_engine_info() seems to be correct solution for vulcan.