Re: [tcf-dev] TCF Service Definitions

[<Michael.Rentschler@xxxxxxxxxxxxx>]

Hi Martin,

this was no show-stopper for us. I understand that TCF was designed to take care of targets with a low performance level and thus the protocol does reflect this
characteristic by some structural draw-backs. Sure I would prefer if TCF would be a little bit more strict on things like error result handling, or completely based on
Json; but that’s another direction.

For now we found a way to continue our work on a Proxy source-code generator. So far we developed a XML schematic that can be used to describe and document
TCF services. We already specified most of the standard TCF services this way. And we have a generator (its .NET, though).

The Java proxies that we generate out of those XML files look a bit different than the TCF proxies do right now. Some small changes was done to simplify the usage.
Our aim is to call TCF service functions directly from a test script (e.g. Groovy unit tests) without the need of any additional wrappers by directly calling the Proxy
methods. That’s why we tried to avoid returning simple Object arrays as a result and do some result preprocessing instead. E. g. the returned result must fit the
service specification and gets converted into a single result parameter of a well-defined structure for type-safety purposes.
Also we would like to throw errors instead to just return them. In case of unit tests, this has the advantage that exceptions will mark the test as failed without
the need of any additional checks (e. g. checks for TCF errors). The test code would become much shorter this way.

For now we found a work-around by searching the service function results for a parameter called "errorReport". If this is non-null it will be thrown. But we also
thought of a more generic way by marking those parameters as "throwable" inside the XML specification.

If you are interested then we can provide you with the XML schematics and service descriptions we have. Currently we are working on a tool that will generate
service documentations out of these files. 

Regards,
Michael

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: Donnerstag, 28. November 2013 15:09
To: TCF Development; Michael Rentschler - M21158
Subject: 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
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev