Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tcf-dev] TCF Service Definitions 
Hi Michael,

In fact TCF Protocol definitions have been put into some products on the market, and changing the protocol specs after the fact would be extremely hard, if not impossible.

Still, "Auto-generate service proxies from XML service descriptions" caught my attention since today, we seem to duplicate quite some work across the protocol specs, Javadocs, C Header docs, Python docs and Lua. Also, consistency across services seems very desirable.

Did you think that Eugene's answer was a blocker for what you were trying to accomplish, or could there be a design that satisfies all our needs - backward compatibility, efficiency and auto-generating proxies ?

I'd love to hear more about your code generating efforts and would be very interested adopting some of these technologies in Open Source.

What do you think ?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6


-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Eugene Tarassov
Sent: Thursday, November 14, 2013 8:59 PM
To: TCF Development
Subject: Re: [tcf-dev] TCF Service Definitions

Hi Michael,

> some service functions, e.g. "FileSystem.read", do return the error as the 2nd argument.

It is intentional. Error as the 2nd argument allows more efficient implementation of the command. On a memory constrained target, the command can send data directly to the output stream instead of allocating a buffer for the whole request. Same for other commands, like "Memory.get".

Regards,
Eugene

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael.Rentschler@xxxxxxxxxxxxx
Sent: Donnerstag, 14. November 2013 08:50
To: tcf-dev@xxxxxxxxxxx
Subject: [tcf-dev] TCF Service Definitions

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
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.



_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev

Back to the top