[tcf-dev] TCF Service Definitions

[<Michael.Rentschler@xxxxxxxxxxxxx>]

Hi,

I wonder why some TCF services use a different scheme for reporting their errors.
Usually the error report is returned inside the first result parameter. But some service functions, e.g. "FileSystem.read", do return the error as the 2nd argument. Is there a plan to cleanup this stuff and to match all default service definitions?

It would be preferably to have a strict style which is used by all default services, especially in the scope of having a code generator for the service proxies (what I am into). My aim is to generate the proxy sources from my XML service description in a way, that the resulting methods can be easily used from my groovy test scripts. E.g. Structures will be generated and encoded/decoded into/from JSON HashMaps. The ErrorReport will be thrown if it was set.

Allowing more than 2 return parameters doesn't make sense if we use JSON inside the parameters itself, since JSON can handle complex result types and even allows to label each.
argument. I mention this, because with having more than 2 return parameters in the default services, my generator is forced to wrap any result inside a generated class, even if this class does only contain one parameter. This results in a 2nd wrapper class that is not really necessary in my eyes:

class TransmitResult {
  int resultValue;
  String executionTime;
}

class TransmitResultResult {
   TransmitResult result;			//2nd result parameter of service function getTransmitResult
}

class MyServiceProxy implements IMyService {
  public TransmitResultResult getTransmitResult() throws ErrorReport {
   ...
  }
  ...
}

The resulting Proxy can be easily used from inside my Groovy test case. For example this one- liner will call the Service function implemented above:

assert myService.getTransmitResult().result.resultValue == 10

That’s the reason why I would suggest to keep the interfaces as simple as possible, even if TCF would allow to have as much result parameters as you wish. It would be great if we could set a limit of 2 result parameters for all default services, where the 1st one is the error report. All services use JSON anyway and can combine all their results inside the 2nd parameter.

I know it would be hard to change service definitions now, since there are many relations and all has to be changed at once. But I would really appreciate to have a strict and simple style here.

Regards,
Michael