[Fiware-middleware] IDL Comments

[Dmitri Rubinstein]

There was a small typo:

4. Combination of 2. and 3.

Best,

Dmitri

On 10/15/14 09:43, Dmitri Rubinstein wrote:
> 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
>
> _______________________________________________
> Fiware-middleware mailing list
> Fiware-middleware at lists.fi-ware.org
> https://lists.fi-ware.org/listinfo/fiware-middleware
>