[Fiware-middleware] IDL Comments

[Dmitri Rubinstein]

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