[Fiware-middleware] IDL Comments

[Dmitri Rubinstein]

Hi Ricardo,

questions are inline.


Am 15. Oktober 2014 08:43:16 MESZ, schrieb Ricardo Gonzalez Moreno <RicardoGonzalez at eprosima.com>:
>Hi,
>
>The annotation examples you've provided are annotation definitions. As
>we decided to rename the word "interface" to word "service" in our IDL,
>we also removed the words "local interface" from the annotation
>definitions.

Ok, but this means you *modified* the original OMG IDL, since it is not just renaming. So what do you mean with *compatibility* to OMG IDL ?

>The main goal of the annotation definitions is to inform anyone what
>annotations your application supports, and how they should be used.

Yes, we have the same feature that I possibly never announced, but it is a part of a grammar published on fi-ware kiara wiki:

annotation HTTPPort {
  i32 value
}

>
>The way your example will be using our IDL is (including the annotation
>definitions):
>
>@Annotation HTTPPort {
>    attribute i32 value;
>};
>
>@Annotation Oneway {
>   attribute boolean value default true;
>};
>
>@Annotation Encrypted {
>   attribute boolean value default true;
>};
>
>@Annotation OptionallyEncrypted {
>   attribute boolean value default true;
>};
>
>namespace enc {
>
>// HTTPPort annotates the 'enc' service with argument 8080
>@HTTPPort(8080)
>service enc {
>
>    // Function ping is annotated with Oneway and Encrypted annotations
>      // without parameters
>      @Oneway
>      @Encrypted
>      void ping()
>
>      // In function saveString Argument s of type string
>      // is annotated with annotation OptionallyEncrypted without
>      // parameters
>      void saveString(string fileName, @OptionallyEncrypted string s)
>
>      // Return type of function loadString is annotated with
>      // annotation OptionallyEncrypted without parameters
>     @OptionallyEncrypted string loadString(string fileName)
>}
>};

This is a bit strange. Annotation for loadString is done in the same way as for ping. But for loadString only the return type should be annotated, not a complete function like for ping.

For security there is a demand to encrypt either:
1. Complete function: all arguments and return type
2. Returned value
3. One or more arguments
4. Combination of 2. and 4.

This require ability to have different syntaxes for annotating complete function and for just the return type.

>
>OMG IDL annotations can be defined as the user wants, with any number
>of attributes:
>
>   - Annotation definition:
>     @Annotation MyAnnotation {
>         attribute i32 count;
>         attribute string msg;
>     };
>
>   - Annotation usage:
>      @MyAnnotation(count=3, msg="HelloWorld")

Ok, looks pretty like our version.

Thank you for clarification. Still would like to have an answer to my third question from the last mail.

Best,

Dmitri

>
>Best regards,
>Ricardo
>
>El mar, 14-10-2014 a las 13:50 +0200, Dmitri Rubinstein escribió:
>
>
>Hi,
>
>I still have questions and need clarification about IDL proposed by
>eProsima.
>
>1. Originally I understood that eProsima's proposal is *modified* OMG
>IDL and as such is not compatible with the original one. But in last
>meeting there was a statement that besides renaming sequence to list
>and
>interface to service it is fully compatible to OMG IDL. Please give a
>clear statement what are the changes. For example you have this syntax
>in your spec:
>
>@Annotation MyAnnotation {
>    attribute string my_annotation_member_1;
>    // ...
>};
>
>However, I found following annotation example for OMG IDL in Internet:
>
>@Annotation
>local interface Key {
>attribute boolean value default true;
>};
>
>The syntax is different.
>
>2. I need to know how to annotate services, operations/functions,
>return
>types and arguments. I provide here examples in our IDL syntax:
>
>namespace * enc
>
>// HTTPPort annotates the 'enc' service with argument 8080
>[HTTPPort(8080)]
>service enc {
>
>    // Function ping is annotated with Oneway and Encrypted annotations
>     // without parameters
>     [Oneway, Encrypted]
>     void ping()
>
>     // In function saveString Argument s of type string
>     // is annotated with annotation OptionallyEncrypted without
>     // parameters
>     void saveString(string fileName, [OptionallyEncrypted] string s)
>
>     // Return type of function loadString is annotated with
>     // annotation OptionallyEncrypted without parameters
>     string [OptionallyEncrypted] loadString(string fileName)
>}
>
>I also expect that you can annotate a namespace entity that you
>proposed.
>
>3. For me is not clear why support of multiple IDL's require additional
>transformation tools. When I look to the design of the latest rtiddsgen
>2
>(http://community.rti.com/rti-doc/510/ndds/doc/rtiddsgen2/RTI_rtiddsgen_architecture.pptx)
>there is a separation between parser's Raw Tree and AST Tree. Code
>generator is working on the AST tree and not on Parser's Raw Tree tree.
>Having another plug-in parser generating same in-memory representation
>would avoid making text-to-text transformation.
>
>I have same separation, just my tree is not fully AST based. Also I
>need
>to notice that in order to support dynamic functionality from DFKI
>proposal we need to have IDL representation in memory, which I can
>convert back to the IDL.
>
>Best,
>
>Dmitri
>_______________________________________________
>Fiware-middleware mailing list
>Fiware-middleware at lists.fi-ware.org<mailto:Fiware-middleware at lists.fi-ware.org>
>https://lists.fi-ware.org/listinfo/fiware-middleware