[Fiware-middleware] IDL Comments

[Ricardo Gonzalez Moreno]

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.
The main goal of the annotation definitions is to inform anyone what annotations your application supports, and how they should be used.

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)
}
};

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")

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-middleware/attachments/20141015/4ac92981/attachment.html>