From miguel.carrillopacheco at telefonica.com Wed Oct 8 19:41:34 2014 From: miguel.carrillopacheco at telefonica.com (MIGUEL CARRILLO PACHECO) Date: Wed, 8 Oct 2014 19:41:34 +0200 Subject: [Fiware-middleware] Mailing lists of "old WP13" and "old" WP7 (new WP 1.8 and WP 1.5) Message-ID: <5435774E.6010309@telefonica.com> Dear all, First, my apologies to those in the first part of FIWARE but not on the continuation project, please ignore this message. As it seems that you are managing to somehow communicate before I reorganize this, I was reassured to see mails flowing. But it is time to give you a clear scenario as I promised in a message about a week ago. Thing are tricky from outside but for those that are focused on old MiWi it may be easier to understand. I will try to summarise my understanding of this as Juanjo told me it worked, I also add the related lists: Topic "old" FIWARE "new" FIWARE Network WP7 List: old-fiware-i2nd at lists.fi-ware.org (managed by Pier) WP 1.8 List: fiware-i2nd at lists.fi-ware.org (managed by Pier) Robotics (N/A) N/A WP 1.8 List: fiware-robotics at lists.fi-ware.org(managed by Pier) (I guess that they will be also included under fiware-i2nd managed by Pier) Middleware WP13 List: fiware-miwi at lists.fi-ware.org (managed by Christof) Also miwi-middleware at lists.fi-ware.org (managed by Christof and now deprecated) WP 1.8 List: fiware-middleware at lists.fi-ware.org (managed by Christof/Thomas) (I guess that they will be also included under fiware-i2nd managed by Pier) Web UI WP13 List: fiware-miwi at lists.fi-ware.org (managed by Christof) WP 1.5 List: fiware-webui at lists.fi-ware.org (managed by Philipp) For Pier, Christof, Thomas & Philipp: anyone on any of the lists should be added to the general mailing list (fiware at lists.fi-ware.org). Please add them to it whenever you add a new person to the per-chapter lists. Please synchronise now the current lists, I see discrepancies. Note that old "miwi-middleware" is no longer in use. Please delete it from your address books! "miwi-middleware" and "fiware-middleware" are so similar that you may make mistakes. I copied across all the members from miwi-middleware list to fiware-middleware with one exception (we cannot accept non corporate addresses) and two deleted people (a university that is not on board anymore). In summary, this is the list of people there: * aepp at zhaw.ch * andreas.nonnengart at dfki.de * brnr at zhaw.ch * (byelozyorov at cs.uni-saarland.de) -> not in "new" FIWARE, so deleted * fbasr-sek at dfki.de * irenatr at dit.upm.es (it was irenatr at gmail.com) * jaimemartin at eprosima.com * juanjose.hierrosureda at telefonica.com * mach at zhaw.ch * oliver.keller at dfki.de * philipp.slusallek at dfki.de * rafaellara at eprosima.com * ricardogonzalez at eprosima.com * rubenrubio at eprosima.com * (rubinstein at cs.uni-saarland.de) -> not in "new" FIWARE, so deleted * stefan.denne at dfki.de * thomas.bohnert at zhaw.ch * werner.stephan at dfki.de Best regards, Miguel -- Please update your address book with my new e-mail address: miguel.carrillopacheco at telefonica.com ---------------------------------------------------------------------- _/ _/_/ Miguel Carrillo Pacheco _/ _/ _/ _/ Telef?nica Distrito Telef?nica _/ _/_/_/ _/ _/ Investigaci?n y Edifico Oeste 1, Planta 9 _/ _/ _/ _/ Desarrollo Ronda de la Comunicaci?n S/N _/ _/_/ 28050 Madrid (Spain) Tel: (+34) 91 483 26 77 e-mail: miguel.carrillopacheco at telefonica.com Follow FI-WARE on the net Website: http://www.fi-ware.org Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: http://twitter.com/Fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ---------------------------------------------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o -------------- next part -------------- An HTML attachment was scrubbed... URL: From mach at zhaw.ch Tue Oct 14 09:12:34 2014 From: mach at zhaw.ch (Marti Christof (mach)) Date: Tue, 14 Oct 2014 07:12:34 +0000 Subject: [Fiware-middleware] Merged Specification document for todays meeting Message-ID: Hi everybody Here you can find the merged middleware specification document for todays discussion: https://docs.google.com/document/d/13Dr2LsZxY3osXiTiePozwZlI3DSoQpUbhT79_SHQ_YA/edit# I combined the essential content of - eprosima?s specification document: KIARA RPC - eProsima Initial Submission_v0.2.0.odt - DFKI?s JAVA-API-v0.3.txt (plus parts from Dmitris code examples) - ZHAW submission from last week. It is essentially 5 parts: - Overview: specifying the different ?operation modes? of the middleware. We need agree on a common naming and understanding of the different modes. - IDL: IDL proposals and discussion/decision points - Preparation of data types / data mapping - API Usage / Examples: Here I added the different usage examples of the proposals. First how to setup and start the server (in different modes) Second how to setup and start the client (in different modes) - Detailed API Definition: Detailed description and signatures of the involved classes. Additionally I put the complete DFKI-Proposal text in the Appendix. I switched API-Usage and Detailed API Definition, because we should first agree on the general usage of the API, before we can describe the detailed functionality and signatures of the classes. I already added some comments and discussoin points for several sections from my side or from the DFKI document (but I did not scan all the followup emails for comments). See you at 11. Best regards Christof ---- InIT Cloud Computing Lab - ICCLab http://cloudcomp.ch Institut of Applied Information Technology - InIT Zurich University of Applied Sciences - ZHAW School of Engineering Phone: +41 58 934 70 63 Skype: christof-marti From JaimeMartin at eprosima.com Tue Oct 14 10:59:38 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Tue, 14 Oct 2014 08:59:38 +0000 Subject: [Fiware-middleware] Merged Specification document for todays meeting In-Reply-To: References: Message-ID: The hang out link: https://plus.google.com/hangouts/_/gznkmpdp6sr3jmfvnixv3nsu2ma Regards, Jaime. -----Original Message----- From: fiware-middleware-bounces at lists.fi-ware.org [mailto:fiware-middleware-bounces at lists.fi-ware.org] On Behalf Of Marti Christof (mach) Sent: martes, 14 de octubre de 2014 9:13 To: fiware-middleware at lists.fi-ware.org Subject: [Fiware-middleware] Merged Specification document for todays meeting Hi everybody Here you can find the merged middleware specification document for todays discussion: https://docs.google.com/document/d/13Dr2LsZxY3osXiTiePozwZlI3DSoQpUbhT79_SHQ_YA/edit# I combined the essential content of - eprosima?s specification document: KIARA RPC - eProsima Initial Submission_v0.2.0.odt - DFKI?s JAVA-API-v0.3.txt (plus parts from Dmitris code examples) - ZHAW submission from last week. It is essentially 5 parts: - Overview: specifying the different ?operation modes? of the middleware. We need agree on a common naming and understanding of the different modes. - IDL: IDL proposals and discussion/decision points - Preparation of data types / data mapping - API Usage / Examples: Here I added the different usage examples of the proposals. First how to setup and start the server (in different modes) Second how to setup and start the client (in different modes) - Detailed API Definition: Detailed description and signatures of the involved classes. Additionally I put the complete DFKI-Proposal text in the Appendix. I switched API-Usage and Detailed API Definition, because we should first agree on the general usage of the API, before we can describe the detailed functionality and signatures of the classes. I already added some comments and discussoin points for several sections from my side or from the DFKI document (but I did not scan all the followup emails for comments). See you at 11. Best regards Christof ---- InIT Cloud Computing Lab - ICCLab http://cloudcomp.ch Institut of Applied Information Technology - InIT Zurich University of Applied Sciences - ZHAW School of Engineering Phone: +41 58 934 70 63 Skype: christof-marti _______________________________________________ Fiware-middleware mailing list Fiware-middleware at lists.fi-ware.org https://lists.fi-ware.org/listinfo/fiware-middleware ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: 09/08/14 Internal Virus Database is out of date. From Dmitri.Rubinstein at dfki.de Tue Oct 14 13:50:48 2014 From: Dmitri.Rubinstein at dfki.de (Dmitri Rubinstein) Date: Tue, 14 Oct 2014 13:50:48 +0200 Subject: [Fiware-middleware] IDL Comments Message-ID: <543D0E18.4040306@dfki.de> 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 From RicardoGonzalez at eprosima.com Wed Oct 15 08:43:16 2014 From: RicardoGonzalez at eprosima.com (Ricardo Gonzalez Moreno) Date: Wed, 15 Oct 2014 06:43:16 +0000 Subject: [Fiware-middleware] IDL Comments In-Reply-To: <543D0E18.4040306@dfki.de> References: <543D0E18.4040306@dfki.de> Message-ID: <1413355396.3530.16.camel@ricardodesktop> 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 https://lists.fi-ware.org/listinfo/fiware-middleware -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitri.rubinstein at dfki.de Wed Oct 15 09:43:45 2014 From: dmitri.rubinstein at dfki.de (Dmitri Rubinstein) Date: Wed, 15 Oct 2014 09:43:45 +0200 Subject: [Fiware-middleware] IDL Comments In-Reply-To: <1413355396.3530.16.camel@ricardodesktop> References: <543D0E18.4040306@dfki.de> <1413355396.3530.16.camel@ricardodesktop> Message-ID: Hi Ricardo, questions are inline. Am 15. Oktober 2014 08:43:16 MESZ, schrieb 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. 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 >https://lists.fi-ware.org/listinfo/fiware-middleware From mailer at doodle.com Wed Oct 15 10:17:03 2014 From: mailer at doodle.com (Jaime Martin Losa (via Doodle)) Date: Wed, 15 Oct 2014 10:17:03 +0200 (CEST) Subject: [Fiware-middleware] KIARA API Discussion Message-ID: <610289755.1909933.1413361023500.POLL_INVITECONTACT_PARTICIPANT_INVITATION.doodle@worker2> Hi there, Jaime Martin Losa (JaimeMartin at eProsima.com) invites you to participate in the Doodle poll "KIARA API Discussion". Participate now https://doodle.com/6xratkvyqnn3p2er?tmail=poll_invitecontact_participant_invitation&tlink=pollbtn What is Doodle? Doodle is a web service that helps Jaime Martin Losa to find a suitable date for meeting with a group of people. Learn more about how Doodle works. (https://doodle.com/main.html?tlink=checkOutLink&tmail=poll_invitecontact_participant_invitation) ---------------------------------------------------------------------- You have received this e-mail because "Jaime Martin Losa" has invited you to participate in the Doodle poll "KIARA API Discussion." ---- Doodle AG, Werdstrasse 21, 8021 Z?rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dmitri.Rubinstein at dfki.de Wed Oct 15 10:24:08 2014 From: Dmitri.Rubinstein at dfki.de (Dmitri Rubinstein) Date: Wed, 15 Oct 2014 10:24:08 +0200 Subject: [Fiware-middleware] IDL Comments In-Reply-To: References: <543D0E18.4040306@dfki.de> <1413355396.3530.16.camel@ricardodesktop> Message-ID: <543E2F28.5070702@dfki.de> 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 : >> 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 >> 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 > From JaimeMartin at eprosima.com Mon Oct 20 17:01:35 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Mon, 20 Oct 2014 15:01:35 +0000 Subject: [Fiware-middleware] hang out link Message-ID: <123dc5446d13451e8e5227670472329b@AM2PR06MB0929.eurprd06.prod.outlook.com> https://plus.google.com/hangouts/_/g4co6hx5wq4dec5i43octrmsvya Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFEC87.7FD29140] The Middleware Experts Phone: + 34 91 804 34 48 / + 34 607 91 37 45 JaimeMartin at eProsima.com www.eProsima.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3800 bytes Desc: image001.png URL: From Dmitri.Rubinstein at dfki.de Tue Oct 21 14:13:09 2014 From: Dmitri.Rubinstein at dfki.de (Dmitri Rubinstein) Date: Tue, 21 Oct 2014 14:13:09 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal Message-ID: <54464DD5.2020409@dfki.de> Hi all, as discussed in the last meeting I put here information about our IDL proposal. When final document appears online I will copy this text to it. 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar available here: https://thrift.apache.org/docs/idl Our grammar is available here: https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language Note: our goal was not to keep a full backwards compatibility with Thrift, but to modify a grammar only when necessary. Still technically we can be backwards compatible (we can parse already *existing* Thrift IDL files), since we avoided to remove any functionality from Thrift (only 'oneway' keyword was removed, see below). However, this was not tested yet. 2. We did following modifications: 2.1 Base types 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). 'boolean' is used more frequently than 'bool' in other IDLs. We can switch back to 'bool' if desired. 'byte' as a signed integer is not consistent with names of other signed integers (i16, i32, i64). We can switch back to 'byte' as signed 8-bit integer and use 'ubyte' as unsigned 8-bit integer if desired. A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, etc. is here: https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types 2.2 Annotations The official Thirft grammar available on the web (see link above) *does not* contain flexible annotation syntax. There is an annotation support available in the latest Thrift version: https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift However, annotations are limited to key-value pairs and even more important: seems that function arguments and return types can't be annotated, there are at least no examples. Instead of using Thrift annotations we decided to introduce a different syntax inspired by WebIDL: http://www.w3.org/TR/WebIDL/#idl-extended-attributes. 2.2.1 Added syntax for defining custom annotations, similar to structs and exceptions: annotation HTTPPort { i32 port = 80 } 2.2.2 Added ability to annotate following entities: services, service functions, return types of service functions, arguments of service functions. We need this especially for security-related features. For example: 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) } Also see our documentation: https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 2.3 Generic types Original Thrift IDL supports following predefined container types: list, map, and set. We decided to extend this syntax to arbitrary generic types: GenericType where Ti can be either type or constant. In this way we can support types like bounded arrays but still keep backwards compatibility with the original syntax: array< i32, 2> // bounded array of size 2 array< i32, array< i32, 4> > // two-dimensional array 2.4 Removed Thrift features We removed 'oneway' keyword from Thrift because we can use annotation Oneway: Original Thrift: service Test { oneway void zip() } Our grammar: service Test { [Oneway] void ping() } If backwards-compatibility to Thrift is desired we can try to support both styles. 2.5 Unused Thrift features We currently parse but ignore following Thrift features that are missing in OMG IDL: Struct fields can have optional integer identifier. Struct fields can be 'required' or 'optional'. 2.6 Planned extensions Thrift does not provide entity like CORBA's 'module'. The namespace keyword used by Thrift only allow to specify namespace in the generated code. We plan to add module NAME { ... } entity in order to provide support for nested IDL namespaces as well as annotations per module. Best, Dmitri From thomas.bohnert at zhaw.ch Tue Oct 21 14:16:30 2014 From: thomas.bohnert at zhaw.ch (Thomas Michael Bohnert) Date: Tue, 21 Oct 2014 14:16:30 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: References: Message-ID: <54464E9E.9080105@zhaw.ch> Dimitry, Thanks - just one question. Is this starting from the OMG IDL as foundation? I assume so since this was the task to complete. Best - Thomas On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: > Hi all, > > as discussed in the last meeting I put here information about our IDL > proposal. When final document appears online I will copy this text to it. > > 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar > available here: > > https://thrift.apache.org/docs/idl > > Our grammar is available here: > > https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language > > Note: our goal was not to keep a full backwards compatibility with > Thrift, but to modify a grammar only when necessary. Still technically > we can be backwards compatible (we can parse already *existing* Thrift > IDL files), since we avoided to remove any functionality from Thrift > (only 'oneway' keyword was removed, see below). However, this was not > tested yet. > > 2. We did following modifications: > > 2.1 Base types > > 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 > > 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). > > 'boolean' is used more frequently than 'bool' in other IDLs. We can > switch back to 'bool' if desired. > > 'byte' as a signed integer is not consistent with names of other signed > integers (i16, i32, i64). We can switch back to 'byte' as signed 8-bit > integer and use 'ubyte' as unsigned 8-bit integer if desired. > > A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, etc. > is here: > > https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types > > 2.2 Annotations > > The official Thirft grammar available on the web (see link above) *does > not* contain flexible annotation syntax. There is an annotation support > available in the latest Thrift version: > > https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift > > However, annotations are limited to key-value pairs and even more > important: seems that function arguments and return types can't be > annotated, there are at least no examples. > > Instead of using Thrift annotations we decided to introduce a different > syntax inspired by WebIDL: > http://www.w3.org/TR/WebIDL/#idl-extended-attributes. > > 2.2.1 Added syntax for defining custom annotations, similar to structs > and exceptions: > > annotation HTTPPort { > i32 port = 80 > } > > 2.2.2 Added ability to annotate following entities: services, service > functions, return types of service functions, arguments of service > functions. We need this especially for security-related features. For > example: > > 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) > } > > Also see our documentation: > https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 > > 2.3 Generic types > > Original Thrift IDL supports following predefined container types: > list, map, and set. We decided to extend this syntax to > arbitrary generic types: GenericType where Ti can be > either type or constant. In this way we can support types like bounded > arrays but still keep backwards compatibility with the original syntax: > > array< i32, 2> // bounded array of size 2 > array< i32, array< i32, 4> > // two-dimensional array > > 2.4 Removed Thrift features > > We removed 'oneway' keyword from Thrift because we can use annotation > Oneway: > > Original Thrift: > > service Test { > oneway void zip() > } > > Our grammar: > > service Test { > [Oneway] void ping() > } > > If backwards-compatibility to Thrift is desired we can try to support > both styles. > > 2.5 Unused Thrift features > > We currently parse but ignore following Thrift features that are missing > in OMG IDL: > > Struct fields can have optional integer identifier. > Struct fields can be 'required' or 'optional'. > > 2.6 Planned extensions > > Thrift does not provide entity like CORBA's 'module'. The namespace > keyword used by Thrift only allow to specify namespace in the generated > code. We plan to add module NAME { ... } entity in order to provide > support for nested IDL namespaces as well as annotations per module. > > Best, > > Dmitri > _______________________________________________ > Fiware-middleware mailing list > Fiware-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/fiware-middleware > From Dmitri.Rubinstein at dfki.de Tue Oct 21 14:26:39 2014 From: Dmitri.Rubinstein at dfki.de (Dmitri Rubinstein) Date: Tue, 21 Oct 2014 14:26:39 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <54464E9E.9080105@zhaw.ch> References: <54464E9E.9080105@zhaw.ch> Message-ID: <544650FF.1030508@dfki.de> No, our starting point is Thrift IDL, and I describe all differences including a justification. Task with OMG IDL as foundation is eProsima's task, since they are experts in OMG IDL. https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: Deadline Thu EOB Joined document that describes the new IDL Features that have been dropped out of OMG (ePros) Including a justification Features that are proposed by Thrift (DFKI) Including a justification In particular related to features that are required by KIARA innovations Best, Dmitri On 10/21/14 14:16, Thomas Michael Bohnert wrote: > Dimitry, > > Thanks - just one question. Is this starting from the OMG IDL as > foundation? > > I assume so since this was the task to complete. > > Best - Thomas > > On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: >> Hi all, >> >> as discussed in the last meeting I put here information about our IDL >> proposal. When final document appears online I will copy this text to it. >> >> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar >> available here: >> >> https://thrift.apache.org/docs/idl >> >> Our grammar is available here: >> >> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language >> >> >> Note: our goal was not to keep a full backwards compatibility with >> Thrift, but to modify a grammar only when necessary. Still technically >> we can be backwards compatible (we can parse already *existing* Thrift >> IDL files), since we avoided to remove any functionality from Thrift >> (only 'oneway' keyword was removed, see below). However, this was not >> tested yet. >> >> 2. We did following modifications: >> >> 2.1 Base types >> >> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 >> >> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). >> >> 'boolean' is used more frequently than 'bool' in other IDLs. We can >> switch back to 'bool' if desired. >> >> 'byte' as a signed integer is not consistent with names of other signed >> integers (i16, i32, i64). We can switch back to 'byte' as signed 8-bit >> integer and use 'ubyte' as unsigned 8-bit integer if desired. >> >> A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, etc. >> is here: >> >> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types >> >> >> 2.2 Annotations >> >> The official Thirft grammar available on the web (see link above) *does >> not* contain flexible annotation syntax. There is an annotation support >> available in the latest Thrift version: >> >> https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift >> >> However, annotations are limited to key-value pairs and even more >> important: seems that function arguments and return types can't be >> annotated, there are at least no examples. >> >> Instead of using Thrift annotations we decided to introduce a different >> syntax inspired by WebIDL: >> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. >> >> 2.2.1 Added syntax for defining custom annotations, similar to structs >> and exceptions: >> >> annotation HTTPPort { >> i32 port = 80 >> } >> >> 2.2.2 Added ability to annotate following entities: services, service >> functions, return types of service functions, arguments of service >> functions. We need this especially for security-related features. For >> example: >> >> 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) >> } >> >> Also see our documentation: >> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 >> >> >> 2.3 Generic types >> >> Original Thrift IDL supports following predefined container types: >> list, map, and set. We decided to extend this syntax to >> arbitrary generic types: GenericType where Ti can be >> either type or constant. In this way we can support types like bounded >> arrays but still keep backwards compatibility with the original syntax: >> >> array< i32, 2> // bounded array of size 2 >> array< i32, array< i32, 4> > // two-dimensional array >> >> 2.4 Removed Thrift features >> >> We removed 'oneway' keyword from Thrift because we can use annotation >> Oneway: >> >> Original Thrift: >> >> service Test { >> oneway void zip() >> } >> >> Our grammar: >> >> service Test { >> [Oneway] void ping() >> } >> >> If backwards-compatibility to Thrift is desired we can try to support >> both styles. >> >> 2.5 Unused Thrift features >> >> We currently parse but ignore following Thrift features that are missing >> in OMG IDL: >> >> Struct fields can have optional integer identifier. >> Struct fields can be 'required' or 'optional'. >> >> 2.6 Planned extensions >> >> Thrift does not provide entity like CORBA's 'module'. The namespace >> keyword used by Thrift only allow to specify namespace in the generated >> code. We plan to add module NAME { ... } entity in order to provide >> support for nested IDL namespaces as well as annotations per module. >> >> Best, >> >> Dmitri >> _______________________________________________ >> Fiware-middleware mailing list >> Fiware-middleware at lists.fi-ware.org >> https://lists.fi-ware.org/listinfo/fiware-middleware >> From thomas.bohnert at zhaw.ch Tue Oct 21 14:40:32 2014 From: thomas.bohnert at zhaw.ch (Thomas Michael Bohnert) Date: Tue, 21 Oct 2014 14:40:32 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> Message-ID: <54465440.2090801@zhaw.ch> Dimitri, Sorry, but then this is beyond was what requested yesterday. Thanks for your contribution but we wont consider it. Please read the minutes again and start from the OMG-IDL 3.5. Best - Thomas On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: > No, our starting point is Thrift IDL, and I describe all differences > including a justification. Task with OMG IDL as foundation is eProsima's > task, since they are experts in OMG IDL. > > https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: > > Deadline Thu EOB > Joined document that describes the new IDL > Features that have been dropped out of OMG (ePros) > Including a justification > Features that are proposed by Thrift (DFKI) > Including a justification > In particular related to features that are required by KIARA > innovations > > Best, > > Dmitri > > On 10/21/14 14:16, Thomas Michael Bohnert wrote: >> Dimitry, >> >> Thanks - just one question. Is this starting from the OMG IDL as >> foundation? >> >> I assume so since this was the task to complete. >> >> Best - Thomas >> >> On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: >>> Hi all, >>> >>> as discussed in the last meeting I put here information about our IDL >>> proposal. When final document appears online I will copy this text to it. >>> >>> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar >>> available here: >>> >>> https://thrift.apache.org/docs/idl >>> >>> Our grammar is available here: >>> >>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language >>> >>> >>> Note: our goal was not to keep a full backwards compatibility with >>> Thrift, but to modify a grammar only when necessary. Still technically >>> we can be backwards compatible (we can parse already *existing* Thrift >>> IDL files), since we avoided to remove any functionality from Thrift >>> (only 'oneway' keyword was removed, see below). However, this was not >>> tested yet. >>> >>> 2. We did following modifications: >>> >>> 2.1 Base types >>> >>> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 >>> >>> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). >>> >>> 'boolean' is used more frequently than 'bool' in other IDLs. We can >>> switch back to 'bool' if desired. >>> >>> 'byte' as a signed integer is not consistent with names of other signed >>> integers (i16, i32, i64). We can switch back to 'byte' as signed 8-bit >>> integer and use 'ubyte' as unsigned 8-bit integer if desired. >>> >>> A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, etc. >>> is here: >>> >>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types >>> >>> >>> 2.2 Annotations >>> >>> The official Thirft grammar available on the web (see link above) *does >>> not* contain flexible annotation syntax. There is an annotation support >>> available in the latest Thrift version: >>> >>> https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift >>> >>> However, annotations are limited to key-value pairs and even more >>> important: seems that function arguments and return types can't be >>> annotated, there are at least no examples. >>> >>> Instead of using Thrift annotations we decided to introduce a different >>> syntax inspired by WebIDL: >>> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. >>> >>> 2.2.1 Added syntax for defining custom annotations, similar to structs >>> and exceptions: >>> >>> annotation HTTPPort { >>> i32 port = 80 >>> } >>> >>> 2.2.2 Added ability to annotate following entities: services, service >>> functions, return types of service functions, arguments of service >>> functions. We need this especially for security-related features. For >>> example: >>> >>> 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) >>> } >>> >>> Also see our documentation: >>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 >>> >>> >>> 2.3 Generic types >>> >>> Original Thrift IDL supports following predefined container types: >>> list, map, and set. We decided to extend this syntax to >>> arbitrary generic types: GenericType where Ti can be >>> either type or constant. In this way we can support types like bounded >>> arrays but still keep backwards compatibility with the original syntax: >>> >>> array< i32, 2> // bounded array of size 2 >>> array< i32, array< i32, 4> > // two-dimensional array >>> >>> 2.4 Removed Thrift features >>> >>> We removed 'oneway' keyword from Thrift because we can use annotation >>> Oneway: >>> >>> Original Thrift: >>> >>> service Test { >>> oneway void zip() >>> } >>> >>> Our grammar: >>> >>> service Test { >>> [Oneway] void ping() >>> } >>> >>> If backwards-compatibility to Thrift is desired we can try to support >>> both styles. >>> >>> 2.5 Unused Thrift features >>> >>> We currently parse but ignore following Thrift features that are missing >>> in OMG IDL: >>> >>> Struct fields can have optional integer identifier. >>> Struct fields can be 'required' or 'optional'. >>> >>> 2.6 Planned extensions >>> >>> Thrift does not provide entity like CORBA's 'module'. The namespace >>> keyword used by Thrift only allow to specify namespace in the generated >>> code. We plan to add module NAME { ... } entity in order to provide >>> support for nested IDL namespaces as well as annotations per module. >>> >>> Best, >>> >>> Dmitri >>> _______________________________________________ >>> Fiware-middleware mailing list >>> Fiware-middleware at lists.fi-ware.org >>> https://lists.fi-ware.org/listinfo/fiware-middleware >>> > From Dmitri.Rubinstein at dfki.de Tue Oct 21 15:05:55 2014 From: Dmitri.Rubinstein at dfki.de (Dmitri Rubinstein) Date: Tue, 21 Oct 2014 15:05:55 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <54465440.2090801@zhaw.ch> References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> <54465440.2090801@zhaw.ch> Message-ID: <54465A33.9000504@dfki.de> Hi Thomas, On 10/21/14 14:40, Thomas Michael Bohnert wrote: > Dimitri, > > Sorry, but then this is beyond was what requested yesterday. > > Thanks for your contribution but we wont consider it. > > Please read the minutes again and start from the OMG-IDL 3.5. This is just impossible, since first of all we are not experts in OMG-IDL. In order to fulfill your task I need not just to see a OMG-IDL grammar but usage examples for any feature. Thrift provides them as a part of tutorial and test suite, and I refer to them in my text. It is hard to me to find similar OMG IDL examples online. Also because of this Philipp requested yesterday a link to the OMG IDL 3.5 PDF, and I requested answers to my questions regarding annotation examples. What I mean is when somebody would like to convince us to use OMG IDL then they should show how our features described in Thrift IDL will be expressed in OMG IDL. IMHO it does not really matter which spec I use as a foundation since I describe differences together with examples. Also I documented features that AFAIK are missing in OMG IDL (2.5 Unused Thrift features) but are available in Thrift. Best, Dmitri > > Best - Thomas > > On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: >> No, our starting point is Thrift IDL, and I describe all differences >> including a justification. Task with OMG IDL as foundation is eProsima's >> task, since they are experts in OMG IDL. >> >> https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: >> >> >> Deadline Thu EOB >> Joined document that describes the new IDL >> Features that have been dropped out of OMG (ePros) >> Including a justification >> Features that are proposed by Thrift (DFKI) >> Including a justification >> In particular related to features that are required by KIARA >> innovations >> >> Best, >> >> Dmitri >> >> On 10/21/14 14:16, Thomas Michael Bohnert wrote: >>> Dimitry, >>> >>> Thanks - just one question. Is this starting from the OMG IDL as >>> foundation? >>> >>> I assume so since this was the task to complete. >>> >>> Best - Thomas >>> >>> On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: >>>> Hi all, >>>> >>>> as discussed in the last meeting I put here information about our IDL >>>> proposal. When final document appears online I will copy this text >>>> to it. >>>> >>>> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar >>>> available here: >>>> >>>> https://thrift.apache.org/docs/idl >>>> >>>> Our grammar is available here: >>>> >>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language >>>> >>>> >>>> >>>> Note: our goal was not to keep a full backwards compatibility with >>>> Thrift, but to modify a grammar only when necessary. Still technically >>>> we can be backwards compatible (we can parse already *existing* Thrift >>>> IDL files), since we avoided to remove any functionality from Thrift >>>> (only 'oneway' keyword was removed, see below). However, this was not >>>> tested yet. >>>> >>>> 2. We did following modifications: >>>> >>>> 2.1 Base types >>>> >>>> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 >>>> >>>> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). >>>> >>>> 'boolean' is used more frequently than 'bool' in other IDLs. We can >>>> switch back to 'bool' if desired. >>>> >>>> 'byte' as a signed integer is not consistent with names of other signed >>>> integers (i16, i32, i64). We can switch back to 'byte' as signed 8-bit >>>> integer and use 'ubyte' as unsigned 8-bit integer if desired. >>>> >>>> A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, etc. >>>> is here: >>>> >>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types >>>> >>>> >>>> >>>> 2.2 Annotations >>>> >>>> The official Thirft grammar available on the web (see link above) *does >>>> not* contain flexible annotation syntax. There is an annotation support >>>> available in the latest Thrift version: >>>> >>>> https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift >>>> >>>> However, annotations are limited to key-value pairs and even more >>>> important: seems that function arguments and return types can't be >>>> annotated, there are at least no examples. >>>> >>>> Instead of using Thrift annotations we decided to introduce a different >>>> syntax inspired by WebIDL: >>>> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. >>>> >>>> 2.2.1 Added syntax for defining custom annotations, similar to structs >>>> and exceptions: >>>> >>>> annotation HTTPPort { >>>> i32 port = 80 >>>> } >>>> >>>> 2.2.2 Added ability to annotate following entities: services, service >>>> functions, return types of service functions, arguments of service >>>> functions. We need this especially for security-related features. For >>>> example: >>>> >>>> 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) >>>> } >>>> >>>> Also see our documentation: >>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 >>>> >>>> >>>> >>>> 2.3 Generic types >>>> >>>> Original Thrift IDL supports following predefined container types: >>>> list, map, and set. We decided to extend this syntax to >>>> arbitrary generic types: GenericType where Ti can be >>>> either type or constant. In this way we can support types like bounded >>>> arrays but still keep backwards compatibility with the original syntax: >>>> >>>> array< i32, 2> // bounded array of size 2 >>>> array< i32, array< i32, 4> > // two-dimensional array >>>> >>>> 2.4 Removed Thrift features >>>> >>>> We removed 'oneway' keyword from Thrift because we can use annotation >>>> Oneway: >>>> >>>> Original Thrift: >>>> >>>> service Test { >>>> oneway void zip() >>>> } >>>> >>>> Our grammar: >>>> >>>> service Test { >>>> [Oneway] void ping() >>>> } >>>> >>>> If backwards-compatibility to Thrift is desired we can try to support >>>> both styles. >>>> >>>> 2.5 Unused Thrift features >>>> >>>> We currently parse but ignore following Thrift features that are >>>> missing >>>> in OMG IDL: >>>> >>>> Struct fields can have optional integer identifier. >>>> Struct fields can be 'required' or 'optional'. >>>> >>>> 2.6 Planned extensions >>>> >>>> Thrift does not provide entity like CORBA's 'module'. The namespace >>>> keyword used by Thrift only allow to specify namespace in the generated >>>> code. We plan to add module NAME { ... } entity in order to provide >>>> support for nested IDL namespaces as well as annotations per module. >>>> >>>> Best, >>>> >>>> Dmitri >>>> _______________________________________________ >>>> Fiware-middleware mailing list >>>> Fiware-middleware at lists.fi-ware.org >>>> https://lists.fi-ware.org/listinfo/fiware-middleware >>>> >> From bothom at gmail.com Tue Oct 21 15:11:35 2014 From: bothom at gmail.com (Thomas Michael Bohnert) Date: Tue, 21 Oct 2014 15:11:35 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> <54465440.2090801@zhaw.ch> Message-ID: <54465B87.4060303@gmail.com> HI Dimitry, The starting point will be OMG IDL 3.5. You will sooner or later have to get familiar with it. Please adhere to that decision and use the time to get into the topic. If you need some more time to study it please let me know. I will have a look into what you have provided but we will not start from a Thrift foundation. Thanks for your cooperation, Thomas On 10/21/2014 03:05 PM, Dmitri Rubinstein wrote: > Hi Thomas, > > On 10/21/14 14:40, Thomas Michael Bohnert wrote: >> Dimitri, >> >> Sorry, but then this is beyond was what requested yesterday. >> >> Thanks for your contribution but we wont consider it.HI >> >> Please read the minutes again and start from the OMG-IDL 3.5. > > This is just impossible, since first of all we are not experts in > OMG-IDL. In order to fulfill your task I need not just to see a OMG-IDL > grammar but usage examples for any feature. Thrift provides them as a > part of tutorial and test suite, and I refer to them in my text. It is > hard to me to find similar OMG IDL examples online. > > Also because of this Philipp requested yesterday a link to the OMG IDL > 3.5 PDF, and I requested answers to my questions regarding annotation > examples. What I mean is when somebody would like to convince us to use > OMG IDL then they should show how our features described in Thrift IDL > will be expressed in OMG IDL. > > IMHO it does not really matter which spec I use as a foundation since I > describe differences together with examples. Also I documented features > that AFAIK are missing in OMG IDL (2.5 Unused Thrift features) but are > available in Thrift. > > Best, > > Dmitri > >> >> Best - Thomas >> >> On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: >>> No, our starting point is Thrift IDL, and I describe all differences >>> including a justification. Task with OMG IDL as foundation is eProsima's >>> task, since they are experts in OMG IDL. >>> >>> https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: >>> >>> >>> Deadline Thu EOB >>> Joined document that describes the new IDL >>> Features that have been dropped out of OMG (ePros) >>> Including a justification >>> Features that are proposed by Thrift (DFKI) >>> Including a justification >>> In particular related to features that are required by KIARA >>> innovations >>> >>> Best, >>> >>> Dmitri >>> >>> On 10/21/14 14:16, Thomas Michael Bohnert wrote: >>>> Dimitry, >>>> >>>> Thanks - just one question. Is this starting from the OMG IDL as >>>> foundation? >>>> >>>> I assume so since this was the task to complete. >>>> >>>> Best - Thomas >>>> >>>> On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: >>>>> Hi all, >>>>> >>>>> as discussed in the last meeting I put here information about our IDL >>>>> proposal. When final document appears online I will copy this text >>>>> to it. >>>>> >>>>> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar >>>>> available here: >>>>> >>>>> https://thrift.apache.org/docs/idl >>>>> >>>>> Our grammar is available here: >>>>> >>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language >>>>> >>>>> >>>>> >>>>> Note: our goal was not to keep a full backwards compatibility with >>>>> Thrift, but to modify a grammar only when necessary. Still technically >>>>> we can be backwards compatible (we can parse already *existing* Thrift >>>>> IDL files), since we avoided to remove any functionality from Thrift >>>>> (only 'oneway' keyword was removed, see below). However, this was not >>>>> tested yet. >>>>> >>>>> 2. We did following modifications: >>>>> >>>>> 2.1 Base types >>>>> >>>>> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 >>>>> >>>>> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). >>>>> >>>>> 'boolean' is used more frequently than 'bool' in other IDLs. We can >>>>> switch back to 'bool' if desired. >>>>> >>>>> 'byte' as a signed integer is not consistent with names of other signed >>>>> integers (i16, i32, i64). We can switch back to 'byte' as signed 8-bit >>>>> integer and use 'ubyte' as unsigned 8-bit integer if desired. >>>>> >>>>> A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, etc. >>>>> is here: >>>>> >>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types >>>>> >>>>> >>>>> >>>>> 2.2 Annotations >>>>> >>>>> The official Thirft grammar available on the web (see link above) *does >>>>> not* contain flexible annotation syntax. There is an annotation support >>>>> available in the latest Thrift version: >>>>> >>>>> https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift >>>>> >>>>> However, annotations are limited to key-value pairs and even more >>>>> important: seems that function arguments and return types can't be >>>>> annotated, there are at least no examples. >>>>> >>>>> Instead of using Thrift annotations we decided to introduce a different >>>>> syntax inspired by WebIDL: >>>>> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. >>>>> >>>>> 2.2.1 Added syntax for defining custom annotations, similar to structs >>>>> and exceptions: >>>>> >>>>> annotation HTTPPort { >>>>> i32 port = 80 >>>>> } >>>>> >>>>> 2.2.2 Added ability to annotate following entities: services, service >>>>> functions, return types of service functions, arguments of service >>>>> functions. We need this especially for security-related features. For >>>>> example: >>>>> >>>>> 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) >>>>> } >>>>> >>>>> Also see our documentation: >>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 >>>>> >>>>> >>>>> >>>>> 2.3 Generic types >>>>> >>>>> Original Thrift IDL supports following predefined container types: >>>>> list, map, and set. We decided to extend this syntax to >>>>> arbitrary generic types: GenericType where Ti can be >>>>> either type or constant. In this way we can support types like bounded >>>>> arrays but still keep backwards compatibility with the original syntax: >>>>> >>>>> array< i32, 2> // bounded array of size 2 >>>>> array< i32, array< i32, 4> > // two-dimensional array >>>>> >>>>> 2.4 Removed Thrift features >>>>> >>>>> We removed 'oneway' keyword from Thrift because we can use annotation >>>>> Oneway: >>>>> >>>>> Original Thrift: >>>>> >>>>> service Test { >>>>> oneway void zip() >>>>> } >>>>> >>>>> Our grammar: >>>>> >>>>> service Test { >>>>> [Oneway] void ping() >>>>> } >>>>> >>>>> If backwards-compatibility to Thrift is desired we can try to support >>>>> both styles. >>>>> >>>>> 2.5 Unused Thrift features >>>>> >>>>> We currently parse but ignore following Thrift features that are >>>>> missing >>>>> in OMG IDL: >>>>> >>>>> Struct fields can have optional integer identifier. >>>>> Struct fields can be 'required' or 'optional'. >>>>> >>>>> 2.6 Planned extensions >>>>> >>>>> Thrift does not provide entity like CORBA's 'module'. The namespace >>>>> keyword used by Thrift only allow to specify namespace in the generated >>>>> code. We plan to add module NAME { ... } entity in order to provide >>>>> support for nested IDL namespaces as well as annotations per module. >>>>> >>>>> Best, >>>>> >>>>> Dmitri >>>>> _______________________________________________ >>>>> Fiware-middleware mailing list >>>>> Fiware-middleware at lists.fi-ware.org >>>>> https://lists.fi-ware.org/listinfo/fiware-middleware >>>>> >>> > -- Thomas Michael Bohnert, PhD Head of Service Engineering (ICCLab, SPLab) Zurich University of Applied Sciences eMail: thomas.bohnert at zhaw.ch mobile: +41791758136 web: www.cloudcomp.ch, tmb.nginet.de twitter: tmbohnert skype: tbohnert From philipp.slusallek at dfki.de Tue Oct 21 22:32:14 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Tue, 21 Oct 2014 22:32:14 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <54465B87.4060303@gmail.com> References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> <54465440.2090801@zhaw.ch> <54465B87.4060303@gmail.com> Message-ID: <5446C2CE.0@dfki.de> Hi all, What Dmitri has provided is a clear and concise summary of what we have changed from the current Thrift version. These are the features that we need in the new IDL. [BTW, it also show that our proposal is very close to the Thrift standard and almost completely backwards compatible (and easily can be made completely compatible).] Since we do not have a description of the proposal (OMG-based IDl) from Jaime yet, he has formulated the changes with respect to the only thing that makes sense for us. I believe it should be trivial for anyone familiar with OMG IDL (and in particular with the changed version that has been proposed but where we still do not know what the changes really are) to check if suitable features are supported or not, and think about ways to achieve them. Jaime is in a much better position to do that then we are. Ideally, he can start with Dmitri's document and can include any needed features directly into his proposal as part of the joint document we wanted to provide. So, I cannot see anything that Dmitri might have done "wrong" (other than that some people seem to be allergic to the string "Thrift", which is becoming a bit bizarre -- to tell the truth :-). Best, Philipp Am 21.10.2014 um 15:11 schrieb Thomas Michael Bohnert: > HI Dimitry, > > The starting point will be OMG IDL 3.5. You will sooner or later have to > get familiar with it. > > Please adhere to that decision and use the time to get into the topic. > If you need some more time to study it please let me know. > > I will have a look into what you have provided but we will not start > from a Thrift foundation. > > Thanks for your cooperation, > Thomas > > On 10/21/2014 03:05 PM, Dmitri Rubinstein wrote: >> Hi Thomas, >> >> On 10/21/14 14:40, Thomas Michael Bohnert wrote: >>> Dimitri, >>> >>> Sorry, but then this is beyond was what requested yesterday. >>> >>> Thanks for your contribution but we wont consider it.HI >>> >>> Please read the minutes again and start from the OMG-IDL 3.5. >> >> This is just impossible, since first of all we are not experts in >> OMG-IDL. In order to fulfill your task I need not just to see a OMG-IDL >> grammar but usage examples for any feature. Thrift provides them as a >> part of tutorial and test suite, and I refer to them in my text. It is >> hard to me to find similar OMG IDL examples online. >> >> Also because of this Philipp requested yesterday a link to the OMG IDL >> 3.5 PDF, and I requested answers to my questions regarding annotation >> examples. What I mean is when somebody would like to convince us to use >> OMG IDL then they should show how our features described in Thrift IDL >> will be expressed in OMG IDL. >> >> IMHO it does not really matter which spec I use as a foundation since I >> describe differences together with examples. Also I documented features >> that AFAIK are missing in OMG IDL (2.5 Unused Thrift features) but are >> available in Thrift. >> >> Best, >> >> Dmitri >> >>> >>> Best - Thomas >>> >>> On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: >>>> No, our starting point is Thrift IDL, and I describe all differences >>>> including a justification. Task with OMG IDL as foundation is >>>> eProsima's >>>> task, since they are experts in OMG IDL. >>>> >>>> https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: >>>> >>>> >>>> >>>> Deadline Thu EOB >>>> Joined document that describes the new IDL >>>> Features that have been dropped out of OMG (ePros) >>>> Including a justification >>>> Features that are proposed by Thrift (DFKI) >>>> Including a justification >>>> In particular related to features that are required by KIARA >>>> innovations >>>> >>>> Best, >>>> >>>> Dmitri >>>> >>>> On 10/21/14 14:16, Thomas Michael Bohnert wrote: >>>>> Dimitry, >>>>> >>>>> Thanks - just one question. Is this starting from the OMG IDL as >>>>> foundation? >>>>> >>>>> I assume so since this was the task to complete. >>>>> >>>>> Best - Thomas >>>>> >>>>> On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: >>>>>> Hi all, >>>>>> >>>>>> as discussed in the last meeting I put here information about our IDL >>>>>> proposal. When final document appears online I will copy this text >>>>>> to it. >>>>>> >>>>>> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar >>>>>> available here: >>>>>> >>>>>> https://thrift.apache.org/docs/idl >>>>>> >>>>>> Our grammar is available here: >>>>>> >>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Note: our goal was not to keep a full backwards compatibility with >>>>>> Thrift, but to modify a grammar only when necessary. Still >>>>>> technically >>>>>> we can be backwards compatible (we can parse already *existing* >>>>>> Thrift >>>>>> IDL files), since we avoided to remove any functionality from Thrift >>>>>> (only 'oneway' keyword was removed, see below). However, this was not >>>>>> tested yet. >>>>>> >>>>>> 2. We did following modifications: >>>>>> >>>>>> 2.1 Base types >>>>>> >>>>>> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 >>>>>> >>>>>> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). >>>>>> >>>>>> 'boolean' is used more frequently than 'bool' in other IDLs. We can >>>>>> switch back to 'bool' if desired. >>>>>> >>>>>> 'byte' as a signed integer is not consistent with names of other >>>>>> signed >>>>>> integers (i16, i32, i64). We can switch back to 'byte' as signed >>>>>> 8-bit >>>>>> integer and use 'ubyte' as unsigned 8-bit integer if desired. >>>>>> >>>>>> A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, >>>>>> etc. >>>>>> is here: >>>>>> >>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2.2 Annotations >>>>>> >>>>>> The official Thirft grammar available on the web (see link above) >>>>>> *does >>>>>> not* contain flexible annotation syntax. There is an annotation >>>>>> support >>>>>> available in the latest Thrift version: >>>>>> >>>>>> https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift >>>>>> >>>>>> >>>>>> However, annotations are limited to key-value pairs and even more >>>>>> important: seems that function arguments and return types can't be >>>>>> annotated, there are at least no examples. >>>>>> >>>>>> Instead of using Thrift annotations we decided to introduce a >>>>>> different >>>>>> syntax inspired by WebIDL: >>>>>> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. >>>>>> >>>>>> 2.2.1 Added syntax for defining custom annotations, similar to >>>>>> structs >>>>>> and exceptions: >>>>>> >>>>>> annotation HTTPPort { >>>>>> i32 port = 80 >>>>>> } >>>>>> >>>>>> 2.2.2 Added ability to annotate following entities: services, service >>>>>> functions, return types of service functions, arguments of service >>>>>> functions. We need this especially for security-related features. For >>>>>> example: >>>>>> >>>>>> 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) >>>>>> } >>>>>> >>>>>> Also see our documentation: >>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2.3 Generic types >>>>>> >>>>>> Original Thrift IDL supports following predefined container types: >>>>>> list, map, and set. We decided to extend this syntax to >>>>>> arbitrary generic types: GenericType where Ti can be >>>>>> either type or constant. In this way we can support types like >>>>>> bounded >>>>>> arrays but still keep backwards compatibility with the original >>>>>> syntax: >>>>>> >>>>>> array< i32, 2> // bounded array of size 2 >>>>>> array< i32, array< i32, 4> > // two-dimensional array >>>>>> >>>>>> 2.4 Removed Thrift features >>>>>> >>>>>> We removed 'oneway' keyword from Thrift because we can use annotation >>>>>> Oneway: >>>>>> >>>>>> Original Thrift: >>>>>> >>>>>> service Test { >>>>>> oneway void zip() >>>>>> } >>>>>> >>>>>> Our grammar: >>>>>> >>>>>> service Test { >>>>>> [Oneway] void ping() >>>>>> } >>>>>> >>>>>> If backwards-compatibility to Thrift is desired we can try to support >>>>>> both styles. >>>>>> >>>>>> 2.5 Unused Thrift features >>>>>> >>>>>> We currently parse but ignore following Thrift features that are >>>>>> missing >>>>>> in OMG IDL: >>>>>> >>>>>> Struct fields can have optional integer identifier. >>>>>> Struct fields can be 'required' or 'optional'. >>>>>> >>>>>> 2.6 Planned extensions >>>>>> >>>>>> Thrift does not provide entity like CORBA's 'module'. The namespace >>>>>> keyword used by Thrift only allow to specify namespace in the >>>>>> generated >>>>>> code. We plan to add module NAME { ... } entity in order to provide >>>>>> support for nested IDL namespaces as well as annotations per module. >>>>>> >>>>>> Best, >>>>>> >>>>>> Dmitri >>>>>> _______________________________________________ >>>>>> Fiware-middleware mailing list >>>>>> Fiware-middleware at lists.fi-ware.org >>>>>> https://lists.fi-ware.org/listinfo/fiware-middleware >>>>>> >>>> >> > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From Dmitri.Rubinstein at dfki.de Wed Oct 22 11:28:45 2014 From: Dmitri.Rubinstein at dfki.de (Dmitri Rubinstein) Date: Wed, 22 Oct 2014 11:28:45 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <54465B87.4060303@gmail.com> References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> <54465440.2090801@zhaw.ch> <54465B87.4060303@gmail.com> Message-ID: <544778CD.6000906@dfki.de> Hi Thomas, On 10/21/14 15:11, Thomas Michael Bohnert wrote: > HI Dimitry, > > The starting point will be OMG IDL 3.5. You will sooner or later have to > get familiar with it. > > Please adhere to that decision and use the time to get into the topic. > If you need some more time to study it please let me know. Of course I need more time. I received no link to the OMG IDL spec and found with google this one: http://www.omg.org/spec/IDL35/3.5/PDF/. It has 100 pages. As far as I understood we don't plan to support everything, just a subset. But which parts of the spec ? I already found a feature that we can't easily support: preprocessing (Section 5.3). Since DFKI part of the proposal requires IDL processing at the runtime of the program it also requires downloading and parsing of the IDL at the runtime. IDL file with #include directives can only be correctly preprocessed when all included files are downloaded in advance. One option is to support only already preprocessed IDL files without preprocessor directives. Best, Dmitri > > I will have a look into what you have provided but we will not start > from a Thrift foundation. > > Thanks for your cooperation, > Thomas > > On 10/21/2014 03:05 PM, Dmitri Rubinstein wrote: >> Hi Thomas, >> >> On 10/21/14 14:40, Thomas Michael Bohnert wrote: >>> Dimitri, >>> >>> Sorry, but then this is beyond was what requested yesterday. >>> >>> Thanks for your contribution but we wont consider it.HI >>> >>> Please read the minutes again and start from the OMG-IDL 3.5. >> >> This is just impossible, since first of all we are not experts in >> OMG-IDL. In order to fulfill your task I need not just to see a OMG-IDL >> grammar but usage examples for any feature. Thrift provides them as a >> part of tutorial and test suite, and I refer to them in my text. It is >> hard to me to find similar OMG IDL examples online. >> >> Also because of this Philipp requested yesterday a link to the OMG IDL >> 3.5 PDF, and I requested answers to my questions regarding annotation >> examples. What I mean is when somebody would like to convince us to use >> OMG IDL then they should show how our features described in Thrift IDL >> will be expressed in OMG IDL. >> >> IMHO it does not really matter which spec I use as a foundation since I >> describe differences together with examples. Also I documented features >> that AFAIK are missing in OMG IDL (2.5 Unused Thrift features) but are >> available in Thrift. >> >> Best, >> >> Dmitri >> >>> >>> Best - Thomas >>> >>> On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: >>>> No, our starting point is Thrift IDL, and I describe all differences >>>> including a justification. Task with OMG IDL as foundation is >>>> eProsima's >>>> task, since they are experts in OMG IDL. >>>> >>>> https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: >>>> >>>> >>>> >>>> Deadline Thu EOB >>>> Joined document that describes the new IDL >>>> Features that have been dropped out of OMG (ePros) >>>> Including a justification >>>> Features that are proposed by Thrift (DFKI) >>>> Including a justification >>>> In particular related to features that are required by KIARA >>>> innovations >>>> >>>> Best, >>>> >>>> Dmitri >>>> >>>> On 10/21/14 14:16, Thomas Michael Bohnert wrote: >>>>> Dimitry, >>>>> >>>>> Thanks - just one question. Is this starting from the OMG IDL as >>>>> foundation? >>>>> >>>>> I assume so since this was the task to complete. >>>>> >>>>> Best - Thomas >>>>> >>>>> On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: >>>>>> Hi all, >>>>>> >>>>>> as discussed in the last meeting I put here information about our IDL >>>>>> proposal. When final document appears online I will copy this text >>>>>> to it. >>>>>> >>>>>> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar >>>>>> available here: >>>>>> >>>>>> https://thrift.apache.org/docs/idl >>>>>> >>>>>> Our grammar is available here: >>>>>> >>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Note: our goal was not to keep a full backwards compatibility with >>>>>> Thrift, but to modify a grammar only when necessary. Still >>>>>> technically >>>>>> we can be backwards compatible (we can parse already *existing* >>>>>> Thrift >>>>>> IDL files), since we avoided to remove any functionality from Thrift >>>>>> (only 'oneway' keyword was removed, see below). However, this was not >>>>>> tested yet. >>>>>> >>>>>> 2. We did following modifications: >>>>>> >>>>>> 2.1 Base types >>>>>> >>>>>> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 >>>>>> >>>>>> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). >>>>>> >>>>>> 'boolean' is used more frequently than 'bool' in other IDLs. We can >>>>>> switch back to 'bool' if desired. >>>>>> >>>>>> 'byte' as a signed integer is not consistent with names of other >>>>>> signed >>>>>> integers (i16, i32, i64). We can switch back to 'byte' as signed >>>>>> 8-bit >>>>>> integer and use 'ubyte' as unsigned 8-bit integer if desired. >>>>>> >>>>>> A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, >>>>>> etc. >>>>>> is here: >>>>>> >>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2.2 Annotations >>>>>> >>>>>> The official Thirft grammar available on the web (see link above) >>>>>> *does >>>>>> not* contain flexible annotation syntax. There is an annotation >>>>>> support >>>>>> available in the latest Thrift version: >>>>>> >>>>>> https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift >>>>>> >>>>>> >>>>>> However, annotations are limited to key-value pairs and even more >>>>>> important: seems that function arguments and return types can't be >>>>>> annotated, there are at least no examples. >>>>>> >>>>>> Instead of using Thrift annotations we decided to introduce a >>>>>> different >>>>>> syntax inspired by WebIDL: >>>>>> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. >>>>>> >>>>>> 2.2.1 Added syntax for defining custom annotations, similar to >>>>>> structs >>>>>> and exceptions: >>>>>> >>>>>> annotation HTTPPort { >>>>>> i32 port = 80 >>>>>> } >>>>>> >>>>>> 2.2.2 Added ability to annotate following entities: services, service >>>>>> functions, return types of service functions, arguments of service >>>>>> functions. We need this especially for security-related features. For >>>>>> example: >>>>>> >>>>>> 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) >>>>>> } >>>>>> >>>>>> Also see our documentation: >>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2.3 Generic types >>>>>> >>>>>> Original Thrift IDL supports following predefined container types: >>>>>> list, map, and set. We decided to extend this syntax to >>>>>> arbitrary generic types: GenericType where Ti can be >>>>>> either type or constant. In this way we can support types like >>>>>> bounded >>>>>> arrays but still keep backwards compatibility with the original >>>>>> syntax: >>>>>> >>>>>> array< i32, 2> // bounded array of size 2 >>>>>> array< i32, array< i32, 4> > // two-dimensional array >>>>>> >>>>>> 2.4 Removed Thrift features >>>>>> >>>>>> We removed 'oneway' keyword from Thrift because we can use annotation >>>>>> Oneway: >>>>>> >>>>>> Original Thrift: >>>>>> >>>>>> service Test { >>>>>> oneway void zip() >>>>>> } >>>>>> >>>>>> Our grammar: >>>>>> >>>>>> service Test { >>>>>> [Oneway] void ping() >>>>>> } >>>>>> >>>>>> If backwards-compatibility to Thrift is desired we can try to support >>>>>> both styles. >>>>>> >>>>>> 2.5 Unused Thrift features >>>>>> >>>>>> We currently parse but ignore following Thrift features that are >>>>>> missing >>>>>> in OMG IDL: >>>>>> >>>>>> Struct fields can have optional integer identifier. >>>>>> Struct fields can be 'required' or 'optional'. >>>>>> >>>>>> 2.6 Planned extensions >>>>>> >>>>>> Thrift does not provide entity like CORBA's 'module'. The namespace >>>>>> keyword used by Thrift only allow to specify namespace in the >>>>>> generated >>>>>> code. We plan to add module NAME { ... } entity in order to provide >>>>>> support for nested IDL namespaces as well as annotations per module. >>>>>> >>>>>> Best, >>>>>> >>>>>> Dmitri >>>>>> _______________________________________________ >>>>>> Fiware-middleware mailing list >>>>>> Fiware-middleware at lists.fi-ware.org >>>>>> https://lists.fi-ware.org/listinfo/fiware-middleware >>>>>> >>>> >> > From JaimeMartin at eprosima.com Wed Oct 22 11:35:07 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Wed, 22 Oct 2014 09:35:07 +0000 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <544778CD.6000906@dfki.de> References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> <54465440.2090801@zhaw.ch> <54465B87.4060303@gmail.com> <544778CD.6000906@dfki.de> Message-ID: <098b383b5e0949b8bcf840d4109175d8@AM2PR06MB0929.eurprd06.prod.outlook.com> Hi Dimitri, We will send you soon an updated document about this. Please be patient. Regards, Jaime. -----Original Message----- From: fiware-middleware-bounces at lists.fi-ware.org [mailto:fiware-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri Rubinstein Sent: mi?rcoles, 22 de octubre de 2014 11:29 To: Thomas Michael Bohnert; Bohnert Thomas Michael (bohe); fiware-middleware at lists.fi-ware.org Subject: Re: [Fiware-middleware] DFKI Thrift-based IDL Proposal Hi Thomas, On 10/21/14 15:11, Thomas Michael Bohnert wrote: > HI Dimitry, > > The starting point will be OMG IDL 3.5. You will sooner or later have > to get familiar with it. > > Please adhere to that decision and use the time to get into the topic. > If you need some more time to study it please let me know. Of course I need more time. I received no link to the OMG IDL spec and found with google this one: http://www.omg.org/spec/IDL35/3.5/PDF/. It has 100 pages. As far as I understood we don't plan to support everything, just a subset. But which parts of the spec ? I already found a feature that we can't easily support: preprocessing (Section 5.3). Since DFKI part of the proposal requires IDL processing at the runtime of the program it also requires downloading and parsing of the IDL at the runtime. IDL file with #include directives can only be correctly preprocessed when all included files are downloaded in advance. One option is to support only already preprocessed IDL files without preprocessor directives. Best, Dmitri > > I will have a look into what you have provided but we will not start > from a Thrift foundation. > > Thanks for your cooperation, > Thomas > > On 10/21/2014 03:05 PM, Dmitri Rubinstein wrote: >> Hi Thomas, >> >> On 10/21/14 14:40, Thomas Michael Bohnert wrote: >>> Dimitri, >>> >>> Sorry, but then this is beyond was what requested yesterday. >>> >>> Thanks for your contribution but we wont consider it.HI >>> >>> Please read the minutes again and start from the OMG-IDL 3.5. >> >> This is just impossible, since first of all we are not experts in >> OMG-IDL. In order to fulfill your task I need not just to see a OMG-IDL >> grammar but usage examples for any feature. Thrift provides them as a >> part of tutorial and test suite, and I refer to them in my text. It is >> hard to me to find similar OMG IDL examples online. >> >> Also because of this Philipp requested yesterday a link to the OMG IDL >> 3.5 PDF, and I requested answers to my questions regarding annotation >> examples. What I mean is when somebody would like to convince us to use >> OMG IDL then they should show how our features described in Thrift IDL >> will be expressed in OMG IDL. >> >> IMHO it does not really matter which spec I use as a foundation since I >> describe differences together with examples. Also I documented features >> that AFAIK are missing in OMG IDL (2.5 Unused Thrift features) but are >> available in Thrift. >> >> Best, >> >> Dmitri >> >>> >>> Best - Thomas >>> >>> On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: >>>> No, our starting point is Thrift IDL, and I describe all differences >>>> including a justification. Task with OMG IDL as foundation is >>>> eProsima's >>>> task, since they are experts in OMG IDL. >>>> >>>> https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: >>>> >>>> >>>> >>>> Deadline Thu EOB >>>> Joined document that describes the new IDL >>>> Features that have been dropped out of OMG (ePros) >>>> Including a justification >>>> Features that are proposed by Thrift (DFKI) >>>> Including a justification >>>> In particular related to features that are required by KIARA >>>> innovations >>>> >>>> Best, >>>> >>>> Dmitri >>>> >>>> On 10/21/14 14:16, Thomas Michael Bohnert wrote: >>>>> Dimitry, >>>>> >>>>> Thanks - just one question. Is this starting from the OMG IDL as >>>>> foundation? >>>>> >>>>> I assume so since this was the task to complete. >>>>> >>>>> Best - Thomas >>>>> >>>>> On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: >>>>>> Hi all, >>>>>> >>>>>> as discussed in the last meeting I put here information about our IDL >>>>>> proposal. When final document appears online I will copy this text >>>>>> to it. >>>>>> >>>>>> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar >>>>>> available here: >>>>>> >>>>>> https://thrift.apache.org/docs/idl >>>>>> >>>>>> Our grammar is available here: >>>>>> >>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Note: our goal was not to keep a full backwards compatibility with >>>>>> Thrift, but to modify a grammar only when necessary. Still >>>>>> technically >>>>>> we can be backwards compatible (we can parse already *existing* >>>>>> Thrift >>>>>> IDL files), since we avoided to remove any functionality from Thrift >>>>>> (only 'oneway' keyword was removed, see below). However, this was not >>>>>> tested yet. >>>>>> >>>>>> 2. We did following modifications: >>>>>> >>>>>> 2.1 Base types >>>>>> >>>>>> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 >>>>>> >>>>>> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). >>>>>> >>>>>> 'boolean' is used more frequently than 'bool' in other IDLs. We can >>>>>> switch back to 'bool' if desired. >>>>>> >>>>>> 'byte' as a signed integer is not consistent with names of other >>>>>> signed >>>>>> integers (i16, i32, i64). We can switch back to 'byte' as signed >>>>>> 8-bit >>>>>> integer and use 'ubyte' as unsigned 8-bit integer if desired. >>>>>> >>>>>> A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, >>>>>> etc. >>>>>> is here: >>>>>> >>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2.2 Annotations >>>>>> >>>>>> The official Thirft grammar available on the web (see link above) >>>>>> *does >>>>>> not* contain flexible annotation syntax. There is an annotation >>>>>> support >>>>>> available in the latest Thrift version: >>>>>> >>>>>> https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift >>>>>> >>>>>> >>>>>> However, annotations are limited to key-value pairs and even more >>>>>> important: seems that function arguments and return types can't be >>>>>> annotated, there are at least no examples. >>>>>> >>>>>> Instead of using Thrift annotations we decided to introduce a >>>>>> different >>>>>> syntax inspired by WebIDL: >>>>>> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. >>>>>> >>>>>> 2.2.1 Added syntax for defining custom annotations, similar to >>>>>> structs >>>>>> and exceptions: >>>>>> >>>>>> annotation HTTPPort { >>>>>> i32 port = 80 >>>>>> } >>>>>> >>>>>> 2.2.2 Added ability to annotate following entities: services, service >>>>>> functions, return types of service functions, arguments of service >>>>>> functions. We need this especially for security-related features. For >>>>>> example: >>>>>> >>>>>> 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) >>>>>> } >>>>>> >>>>>> Also see our documentation: >>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2.3 Generic types >>>>>> >>>>>> Original Thrift IDL supports following predefined container types: >>>>>> list, map, and set. We decided to extend this syntax to >>>>>> arbitrary generic types: GenericType where Ti can be >>>>>> either type or constant. In this way we can support types like >>>>>> bounded >>>>>> arrays but still keep backwards compatibility with the original >>>>>> syntax: >>>>>> >>>>>> array< i32, 2> // bounded array of size 2 >>>>>> array< i32, array< i32, 4> > // two-dimensional array >>>>>> >>>>>> 2.4 Removed Thrift features >>>>>> >>>>>> We removed 'oneway' keyword from Thrift because we can use annotation >>>>>> Oneway: >>>>>> >>>>>> Original Thrift: >>>>>> >>>>>> service Test { >>>>>> oneway void zip() >>>>>> } >>>>>> >>>>>> Our grammar: >>>>>> >>>>>> service Test { >>>>>> [Oneway] void ping() >>>>>> } >>>>>> >>>>>> If backwards-compatibility to Thrift is desired we can try to support >>>>>> both styles. >>>>>> >>>>>> 2.5 Unused Thrift features >>>>>> >>>>>> We currently parse but ignore following Thrift features that are >>>>>> missing >>>>>> in OMG IDL: >>>>>> >>>>>> Struct fields can have optional integer identifier. >>>>>> Struct fields can be 'required' or 'optional'. >>>>>> >>>>>> 2.6 Planned extensions >>>>>> >>>>>> Thrift does not provide entity like CORBA's 'module'. The namespace >>>>>> keyword used by Thrift only allow to specify namespace in the >>>>>> generated >>>>>> code. We plan to add module NAME { ... } entity in order to provide >>>>>> support for nested IDL namespaces as well as annotations per module. >>>>>> >>>>>> Best, >>>>>> >>>>>> Dmitri >>>>>> _______________________________________________ >>>>>> Fiware-middleware mailing list >>>>>> 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 From thomas.bohnert at zhaw.ch Wed Oct 22 11:41:17 2014 From: thomas.bohnert at zhaw.ch (Thomas Michael Bohnert) Date: Wed, 22 Oct 2014 11:41:17 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <098b383b5e0949b8bcf840d4109175d8@AM2PR06MB0929.eurprd06.prod.outlook.com> References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> <54465440.2090801@zhaw.ch> <54465B87.4060303@gmail.com> <544778CD.6000906@dfki.de> <098b383b5e0949b8bcf840d4109175d8@AM2PR06MB0929.eurprd06.prod.outlook.com> Message-ID: <54477BBD.10505@zhaw.ch> Jaime, you need to speed up a bit. We had agreed that you provide feedback asap. Thanks, Thomas On 10/22/2014 11:35 AM, Jaime Martin Losa wrote: > Hi Dimitri, > > We will send you soon an updated document about this. Please be patient. > > Regards, > Jaime. > > -----Original Message----- > From: fiware-middleware-bounces at lists.fi-ware.org [mailto:fiware-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri Rubinstein > Sent: mi?rcoles, 22 de octubre de 2014 11:29 > To: Thomas Michael Bohnert; Bohnert Thomas Michael (bohe); fiware-middleware at lists.fi-ware.org > Subject: Re: [Fiware-middleware] DFKI Thrift-based IDL Proposal > > Hi Thomas, > > On 10/21/14 15:11, Thomas Michael Bohnert wrote: >> HI Dimitry, >> >> The starting point will be OMG IDL 3.5. You will sooner or later have >> to get familiar with it. >> >> Please adhere to that decision and use the time to get into the topic. >> If you need some more time to study it please let me know. > > Of course I need more time. I received no link to the OMG IDL spec and found with google this one: http://www.omg.org/spec/IDL35/3.5/PDF/. It has 100 pages. As far as I understood we don't plan to support everything, just a subset. But which parts of the spec ? > > I already found a feature that we can't easily support: preprocessing (Section 5.3). Since DFKI part of the proposal requires IDL processing at the runtime of the program it also requires downloading and parsing of the IDL at the runtime. IDL file with #include directives can only be correctly preprocessed when all included files are downloaded in advance. One option is to support only already preprocessed IDL files without preprocessor directives. > > Best, > > Dmitri > >> >> I will have a look into what you have provided but we will not start >> from a Thrift foundation. >> >> Thanks for your cooperation, >> Thomas >> >> On 10/21/2014 03:05 PM, Dmitri Rubinstein wrote: >>> Hi Thomas, >>> >>> On 10/21/14 14:40, Thomas Michael Bohnert wrote: >>>> Dimitri, >>>> >>>> Sorry, but then this is beyond was what requested yesterday. >>>> >>>> Thanks for your contribution but we wont consider it.HI >>>> >>>> Please read the minutes again and start from the OMG-IDL 3.5. >>> >>> This is just impossible, since first of all we are not experts in >>> OMG-IDL. In order to fulfill your task I need not just to see a OMG-IDL >>> grammar but usage examples for any feature. Thrift provides them as a >>> part of tutorial and test suite, and I refer to them in my text. It is >>> hard to me to find similar OMG IDL examples online. >>> >>> Also because of this Philipp requested yesterday a link to the OMG IDL >>> 3.5 PDF, and I requested answers to my questions regarding annotation >>> examples. What I mean is when somebody would like to convince us to use >>> OMG IDL then they should show how our features described in Thrift IDL >>> will be expressed in OMG IDL. >>> >>> IMHO it does not really matter which spec I use as a foundation since I >>> describe differences together with examples. Also I documented features >>> that AFAIK are missing in OMG IDL (2.5 Unused Thrift features) but are >>> available in Thrift. >>> >>> Best, >>> >>> Dmitri >>> >>>> >>>> Best - Thomas >>>> >>>> On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: >>>>> No, our starting point is Thrift IDL, and I describe all differences >>>>> including a justification. Task with OMG IDL as foundation is >>>>> eProsima's >>>>> task, since they are experts in OMG IDL. >>>>> >>>>> https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: >>>>> >>>>> >>>>> >>>>> Deadline Thu EOB >>>>> Joined document that describes the new IDL >>>>> Features that have been dropped out of OMG (ePros) >>>>> Including a justification >>>>> Features that are proposed by Thrift (DFKI) >>>>> Including a justification >>>>> In particular related to features that are required by KIARA >>>>> innovations >>>>> >>>>> Best, >>>>> >>>>> Dmitri >>>>> >>>>> On 10/21/14 14:16, Thomas Michael Bohnert wrote: >>>>>> Dimitry, >>>>>> >>>>>> Thanks - just one question. Is this starting from the OMG IDL as >>>>>> foundation? >>>>>> >>>>>> I assume so since this was the task to complete. >>>>>> >>>>>> Best - Thomas >>>>>> >>>>>> On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> as discussed in the last meeting I put here information about our IDL >>>>>>> proposal. When final document appears online I will copy this text >>>>>>> to it. >>>>>>> >>>>>>> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar >>>>>>> available here: >>>>>>> >>>>>>> https://thrift.apache.org/docs/idl >>>>>>> >>>>>>> Our grammar is available here: >>>>>>> >>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Note: our goal was not to keep a full backwards compatibility with >>>>>>> Thrift, but to modify a grammar only when necessary. Still >>>>>>> technically >>>>>>> we can be backwards compatible (we can parse already *existing* >>>>>>> Thrift >>>>>>> IDL files), since we avoided to remove any functionality from Thrift >>>>>>> (only 'oneway' keyword was removed, see below). However, this was not >>>>>>> tested yet. >>>>>>> >>>>>>> 2. We did following modifications: >>>>>>> >>>>>>> 2.1 Base types >>>>>>> >>>>>>> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 >>>>>>> >>>>>>> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). >>>>>>> >>>>>>> 'boolean' is used more frequently than 'bool' in other IDLs. We can >>>>>>> switch back to 'bool' if desired. >>>>>>> >>>>>>> 'byte' as a signed integer is not consistent with names of other >>>>>>> signed >>>>>>> integers (i16, i32, i64). We can switch back to 'byte' as signed >>>>>>> 8-bit >>>>>>> integer and use 'ubyte' as unsigned 8-bit integer if desired. >>>>>>> >>>>>>> A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, >>>>>>> etc. >>>>>>> is here: >>>>>>> >>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2.2 Annotations >>>>>>> >>>>>>> The official Thirft grammar available on the web (see link above) >>>>>>> *does >>>>>>> not* contain flexible annotation syntax. There is an annotation >>>>>>> support >>>>>>> available in the latest Thrift version: >>>>>>> >>>>>>> https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift >>>>>>> >>>>>>> >>>>>>> However, annotations are limited to key-value pairs and even more >>>>>>> important: seems that function arguments and return types can't be >>>>>>> annotated, there are at least no examples. >>>>>>> >>>>>>> Instead of using Thrift annotations we decided to introduce a >>>>>>> different >>>>>>> syntax inspired by WebIDL: >>>>>>> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. >>>>>>> >>>>>>> 2.2.1 Added syntax for defining custom annotations, similar to >>>>>>> structs >>>>>>> and exceptions: >>>>>>> >>>>>>> annotation HTTPPort { >>>>>>> i32 port = 80 >>>>>>> } >>>>>>> >>>>>>> 2.2.2 Added ability to annotate following entities: services, service >>>>>>> functions, return types of service functions, arguments of service >>>>>>> functions. We need this especially for security-related features. For >>>>>>> example: >>>>>>> >>>>>>> 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) >>>>>>> } >>>>>>> >>>>>>> Also see our documentation: >>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2.3 Generic types >>>>>>> >>>>>>> Original Thrift IDL supports following predefined container types: >>>>>>> list, map, and set. We decided to extend this syntax to >>>>>>> arbitrary generic types: GenericType where Ti can be >>>>>>> either type or constant. In this way we can support types like >>>>>>> bounded >>>>>>> arrays but still keep backwards compatibility with the original >>>>>>> syntax: >>>>>>> >>>>>>> array< i32, 2> // bounded array of size 2 >>>>>>> array< i32, array< i32, 4> > // two-dimensional array >>>>>>> >>>>>>> 2.4 Removed Thrift features >>>>>>> >>>>>>> We removed 'oneway' keyword from Thrift because we can use annotation >>>>>>> Oneway: >>>>>>> >>>>>>> Original Thrift: >>>>>>> >>>>>>> service Test { >>>>>>> oneway void zip() >>>>>>> } >>>>>>> >>>>>>> Our grammar: >>>>>>> >>>>>>> service Test { >>>>>>> [Oneway] void ping() >>>>>>> } >>>>>>> >>>>>>> If backwards-compatibility to Thrift is desired we can try to support >>>>>>> both styles. >>>>>>> >>>>>>> 2.5 Unused Thrift features >>>>>>> >>>>>>> We currently parse but ignore following Thrift features that are >>>>>>> missing >>>>>>> in OMG IDL: >>>>>>> >>>>>>> Struct fields can have optional integer identifier. >>>>>>> Struct fields can be 'required' or 'optional'. >>>>>>> >>>>>>> 2.6 Planned extensions >>>>>>> >>>>>>> Thrift does not provide entity like CORBA's 'module'. The namespace >>>>>>> keyword used by Thrift only allow to specify namespace in the >>>>>>> generated >>>>>>> code. We plan to add module NAME { ... } entity in order to provide >>>>>>> support for nested IDL namespaces as well as annotations per module. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Dmitri >>>>>>> _______________________________________________ >>>>>>> Fiware-middleware mailing list >>>>>>> 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 > -- Thomas Michael Bohnert (TMB) Head of Service Engineering (ICCLab, SPLab) Zurich University of Applied Sciences eMail: thomas.bohnert at zhaw.ch mobile: +41791758136 web: www.cloudcomp.ch, tmb.nginet.de twitter: tmbohnert skype: tbohnert From RicardoGonzalez at eprosima.com Wed Oct 22 12:10:48 2014 From: RicardoGonzalez at eprosima.com (Ricardo Gonzalez Moreno) Date: Wed, 22 Oct 2014 10:10:48 +0000 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <54477BBD.10505@zhaw.ch> References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> <54465440.2090801@zhaw.ch> <54465B87.4060303@gmail.com> <544778CD.6000906@dfki.de> <098b383b5e0949b8bcf840d4109175d8@AM2PR06MB0929.eurprd06.prod.outlook.com> <54477BBD.10505@zhaw.ch> Message-ID: <1413972645.2352.10.camel@ricardodesktop> Hi all, I'm working in the document, but it's not finished yet. I need at least 4 hours. The link of the document is: https://docs.google.com/document/d/1Rqi_zwwc-ixdwU9ddAjn83Z24PJP6fpU-Kwhs7wyxOg/edit?usp=sharing Regards, Ricardo El mi?, 22-10-2014 a las 11:41 +0200, Thomas Michael Bohnert escribi?: Jaime, you need to speed up a bit. We had agreed that you provide feedback asap. Thanks, Thomas On 10/22/2014 11:35 AM, Jaime Martin Losa wrote: > Hi Dimitri, > > We will send you soon an updated document about this. Please be patient. > > Regards, > Jaime. > > -----Original Message----- > From: fiware-middleware-bounces at lists.fi-ware.org [mailto:fiware-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri Rubinstein > Sent: mi?rcoles, 22 de octubre de 2014 11:29 > To: Thomas Michael Bohnert; Bohnert Thomas Michael (bohe); fiware-middleware at lists.fi-ware.org > Subject: Re: [Fiware-middleware] DFKI Thrift-based IDL Proposal > > Hi Thomas, > > On 10/21/14 15:11, Thomas Michael Bohnert wrote: >> HI Dimitry, >> >> The starting point will be OMG IDL 3.5. You will sooner or later have >> to get familiar with it. >> >> Please adhere to that decision and use the time to get into the topic. >> If you need some more time to study it please let me know. > > Of course I need more time. I received no link to the OMG IDL spec and found with google this one: http://www.omg.org/spec/IDL35/3.5/PDF/. It has 100 pages. As far as I understood we don't plan to support everything, just a subset. But which parts of the spec ? > > I already found a feature that we can't easily support: preprocessing (Section 5.3). Since DFKI part of the proposal requires IDL processing at the runtime of the program it also requires downloading and parsing of the IDL at the runtime. IDL file with #include directives can only be correctly preprocessed when all included files are downloaded in advance. One option is to support only already preprocessed IDL files without preprocessor directives. > > Best, > > Dmitri > >> >> I will have a look into what you have provided but we will not start >> from a Thrift foundation. >> >> Thanks for your cooperation, >> Thomas >> >> On 10/21/2014 03:05 PM, Dmitri Rubinstein wrote: >>> Hi Thomas, >>> >>> On 10/21/14 14:40, Thomas Michael Bohnert wrote: >>>> Dimitri, >>>> >>>> Sorry, but then this is beyond was what requested yesterday. >>>> >>>> Thanks for your contribution but we wont consider it.HI >>>> >>>> Please read the minutes again and start from the OMG-IDL 3.5. >>> >>> This is just impossible, since first of all we are not experts in >>> OMG-IDL. In order to fulfill your task I need not just to see a OMG-IDL >>> grammar but usage examples for any feature. Thrift provides them as a >>> part of tutorial and test suite, and I refer to them in my text. It is >>> hard to me to find similar OMG IDL examples online. >>> >>> Also because of this Philipp requested yesterday a link to the OMG IDL >>> 3.5 PDF, and I requested answers to my questions regarding annotation >>> examples. What I mean is when somebody would like to convince us to use >>> OMG IDL then they should show how our features described in Thrift IDL >>> will be expressed in OMG IDL. >>> >>> IMHO it does not really matter which spec I use as a foundation since I >>> describe differences together with examples. Also I documented features >>> that AFAIK are missing in OMG IDL (2.5 Unused Thrift features) but are >>> available in Thrift. >>> >>> Best, >>> >>> Dmitri >>> >>>> >>>> Best - Thomas >>>> >>>> On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: >>>>> No, our starting point is Thrift IDL, and I describe all differences >>>>> including a justification. Task with OMG IDL as foundation is >>>>> eProsima's >>>>> task, since they are experts in OMG IDL. >>>>> >>>>> https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: >>>>> >>>>> >>>>> >>>>> Deadline Thu EOB >>>>> Joined document that describes the new IDL >>>>> Features that have been dropped out of OMG (ePros) >>>>> Including a justification >>>>> Features that are proposed by Thrift (DFKI) >>>>> Including a justification >>>>> In particular related to features that are required by KIARA >>>>> innovations >>>>> >>>>> Best, >>>>> >>>>> Dmitri >>>>> >>>>> On 10/21/14 14:16, Thomas Michael Bohnert wrote: >>>>>> Dimitry, >>>>>> >>>>>> Thanks - just one question. Is this starting from the OMG IDL as >>>>>> foundation? >>>>>> >>>>>> I assume so since this was the task to complete. >>>>>> >>>>>> Best - Thomas >>>>>> >>>>>> On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> as discussed in the last meeting I put here information about our IDL >>>>>>> proposal. When final document appears online I will copy this text >>>>>>> to it. >>>>>>> >>>>>>> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar >>>>>>> available here: >>>>>>> >>>>>>> https://thrift.apache.org/docs/idl >>>>>>> >>>>>>> Our grammar is available here: >>>>>>> >>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Note: our goal was not to keep a full backwards compatibility with >>>>>>> Thrift, but to modify a grammar only when necessary. Still >>>>>>> technically >>>>>>> we can be backwards compatible (we can parse already *existing* >>>>>>> Thrift >>>>>>> IDL files), since we avoided to remove any functionality from Thrift >>>>>>> (only 'oneway' keyword was removed, see below). However, this was not >>>>>>> tested yet. >>>>>>> >>>>>>> 2. We did following modifications: >>>>>>> >>>>>>> 2.1 Base types >>>>>>> >>>>>>> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 >>>>>>> >>>>>>> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). >>>>>>> >>>>>>> 'boolean' is used more frequently than 'bool' in other IDLs. We can >>>>>>> switch back to 'bool' if desired. >>>>>>> >>>>>>> 'byte' as a signed integer is not consistent with names of other >>>>>>> signed >>>>>>> integers (i16, i32, i64). We can switch back to 'byte' as signed >>>>>>> 8-bit >>>>>>> integer and use 'ubyte' as unsigned 8-bit integer if desired. >>>>>>> >>>>>>> A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, >>>>>>> etc. >>>>>>> is here: >>>>>>> >>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2.2 Annotations >>>>>>> >>>>>>> The official Thirft grammar available on the web (see link above) >>>>>>> *does >>>>>>> not* contain flexible annotation syntax. There is an annotation >>>>>>> support >>>>>>> available in the latest Thrift version: >>>>>>> >>>>>>> https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift >>>>>>> >>>>>>> >>>>>>> However, annotations are limited to key-value pairs and even more >>>>>>> important: seems that function arguments and return types can't be >>>>>>> annotated, there are at least no examples. >>>>>>> >>>>>>> Instead of using Thrift annotations we decided to introduce a >>>>>>> different >>>>>>> syntax inspired by WebIDL: >>>>>>> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. >>>>>>> >>>>>>> 2.2.1 Added syntax for defining custom annotations, similar to >>>>>>> structs >>>>>>> and exceptions: >>>>>>> >>>>>>> annotation HTTPPort { >>>>>>> i32 port = 80 >>>>>>> } >>>>>>> >>>>>>> 2.2.2 Added ability to annotate following entities: services, service >>>>>>> functions, return types of service functions, arguments of service >>>>>>> functions. We need this especially for security-related features. For >>>>>>> example: >>>>>>> >>>>>>> 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) >>>>>>> } >>>>>>> >>>>>>> Also see our documentation: >>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2.3 Generic types >>>>>>> >>>>>>> Original Thrift IDL supports following predefined container types: >>>>>>> list, map, and set. We decided to extend this syntax to >>>>>>> arbitrary generic types: GenericType where Ti can be >>>>>>> either type or constant. In this way we can support types like >>>>>>> bounded >>>>>>> arrays but still keep backwards compatibility with the original >>>>>>> syntax: >>>>>>> >>>>>>> array< i32, 2> // bounded array of size 2 >>>>>>> array< i32, array< i32, 4> > // two-dimensional array >>>>>>> >>>>>>> 2.4 Removed Thrift features >>>>>>> >>>>>>> We removed 'oneway' keyword from Thrift because we can use annotation >>>>>>> Oneway: >>>>>>> >>>>>>> Original Thrift: >>>>>>> >>>>>>> service Test { >>>>>>> oneway void zip() >>>>>>> } >>>>>>> >>>>>>> Our grammar: >>>>>>> >>>>>>> service Test { >>>>>>> [Oneway] void ping() >>>>>>> } >>>>>>> >>>>>>> If backwards-compatibility to Thrift is desired we can try to support >>>>>>> both styles. >>>>>>> >>>>>>> 2.5 Unused Thrift features >>>>>>> >>>>>>> We currently parse but ignore following Thrift features that are >>>>>>> missing >>>>>>> in OMG IDL: >>>>>>> >>>>>>> Struct fields can have optional integer identifier. >>>>>>> Struct fields can be 'required' or 'optional'. >>>>>>> >>>>>>> 2.6 Planned extensions >>>>>>> >>>>>>> Thrift does not provide entity like CORBA's 'module'. The namespace >>>>>>> keyword used by Thrift only allow to specify namespace in the >>>>>>> generated >>>>>>> code. We plan to add module NAME { ... } entity in order to provide >>>>>>> support for nested IDL namespaces as well as annotations per module. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Dmitri >>>>>>> _______________________________________________ >>>>>>> Fiware-middleware mailing list >>>>>>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From RicardoGonzalez at eprosima.com Wed Oct 22 17:18:03 2014 From: RicardoGonzalez at eprosima.com (Ricardo Gonzalez Moreno) Date: Wed, 22 Oct 2014 15:18:03 +0000 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <1413972645.2352.10.camel@ricardodesktop> References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> <54465440.2090801@zhaw.ch> <54465B87.4060303@gmail.com> <544778CD.6000906@dfki.de> <098b383b5e0949b8bcf840d4109175d8@AM2PR06MB0929.eurprd06.prod.outlook.com> <54477BBD.10505@zhaw.ch> <1413972645.2352.10.camel@ricardodesktop> Message-ID: <1413991083.2352.13.camel@ricardodesktop> Hi all, I finished the document. I believe I shared the document with permission to make comments. Comments are wellcome. There is a section about features needed by DFKI. I believe I didn't forget anything. Regards, Ricardo. El mi?, 22-10-2014 a las 10:10 +0000, Ricardo Gonzalez Moreno escribi?: > Hi all, > > I'm working in the document, but it's not finished yet. I need at > least 4 hours. > The link of the document is: > > https://docs.google.com/document/d/1Rqi_zwwc-ixdwU9ddAjn83Z24PJP6fpU-Kwhs7wyxOg/edit?usp=sharing > > Regards, > Ricardo > > El mi?, 22-10-2014 a las 11:41 +0200, Thomas Michael Bohnert > escribi?: > > Jaime, you need to speed up a bit. We had agreed that you provide > > feedback asap. > > > > Thanks, Thomas > > > > On 10/22/2014 11:35 AM, Jaime Martin Losa wrote: > > > Hi Dimitri, > > > > > > We will send you soon an updated document about this. Please be patient. > > > > > > Regards, > > > Jaime. > > > > > > -----Original Message----- > > > From: fiware-middleware-bounces at lists.fi-ware.org [mailto:fiware-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri Rubinstein > > > Sent: mi?rcoles, 22 de octubre de 2014 11:29 > > > To: Thomas Michael Bohnert; Bohnert Thomas Michael (bohe); fiware-middleware at lists.fi-ware.org > > > Subject: Re: [Fiware-middleware] DFKI Thrift-based IDL Proposal > > > > > > Hi Thomas, > > > > > > On 10/21/14 15:11, Thomas Michael Bohnert wrote: > > >> HI Dimitry, > > >> > > >> The starting point will be OMG IDL 3.5. You will sooner or later have > > >> to get familiar with it. > > >> > > >> Please adhere to that decision and use the time to get into the topic. > > >> If you need some more time to study it please let me know. > > > > > > Of course I need more time. I received no link to the OMG IDL spec and found with google this one: http://www.omg.org/spec/IDL35/3.5/PDF/. It has 100 pages. As far as I understood we don't plan to support everything, just a subset. But which parts of the spec ? > > > > > > I already found a feature that we can't easily support: preprocessing (Section 5.3). Since DFKI part of the proposal requires IDL processing at the runtime of the program it also requires downloading and parsing of the IDL at the runtime. IDL file with #include directives can only be correctly preprocessed when all included files are downloaded in advance. One option is to support only already preprocessed IDL files without preprocessor directives. > > > > > > Best, > > > > > > Dmitri > > > > > >> > > >> I will have a look into what you have provided but we will not start > > >> from a Thrift foundation. > > >> > > >> Thanks for your cooperation, > > >> Thomas > > >> > > >> On 10/21/2014 03:05 PM, Dmitri Rubinstein wrote: > > >>> Hi Thomas, > > >>> > > >>> On 10/21/14 14:40, Thomas Michael Bohnert wrote: > > >>>> Dimitri, > > >>>> > > >>>> Sorry, but then this is beyond was what requested yesterday. > > >>>> > > >>>> Thanks for your contribution but we wont consider it.HI > > >>>> > > >>>> Please read the minutes again and start from the OMG-IDL 3.5. > > >>> > > >>> This is just impossible, since first of all we are not experts in > > >>> OMG-IDL. In order to fulfill your task I need not just to see a OMG-IDL > > >>> grammar but usage examples for any feature. Thrift provides them as a > > >>> part of tutorial and test suite, and I refer to them in my text. It is > > >>> hard to me to find similar OMG IDL examples online. > > >>> > > >>> Also because of this Philipp requested yesterday a link to the OMG IDL > > >>> 3.5 PDF, and I requested answers to my questions regarding annotation > > >>> examples. What I mean is when somebody would like to convince us to use > > >>> OMG IDL then they should show how our features described in Thrift IDL > > >>> will be expressed in OMG IDL. > > >>> > > >>> IMHO it does not really matter which spec I use as a foundation since I > > >>> describe differences together with examples. Also I documented features > > >>> that AFAIK are missing in OMG IDL (2.5 Unused Thrift features) but are > > >>> available in Thrift. > > >>> > > >>> Best, > > >>> > > >>> Dmitri > > >>> > > >>>> > > >>>> Best - Thomas > > >>>> > > >>>> On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: > > >>>>> No, our starting point is Thrift IDL, and I describe all differences > > >>>>> including a justification. Task with OMG IDL as foundation is > > >>>>> eProsima's > > >>>>> task, since they are experts in OMG IDL. > > >>>>> > > >>>>> https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: > > >>>>> > > >>>>> > > >>>>> > > >>>>> Deadline Thu EOB > > >>>>> Joined document that describes the new IDL > > >>>>> Features that have been dropped out of OMG (ePros) > > >>>>> Including a justification > > >>>>> Features that are proposed by Thrift (DFKI) > > >>>>> Including a justification > > >>>>> In particular related to features that are required by KIARA > > >>>>> innovations > > >>>>> > > >>>>> Best, > > >>>>> > > >>>>> Dmitri > > >>>>> > > >>>>> On 10/21/14 14:16, Thomas Michael Bohnert wrote: > > >>>>>> Dimitry, > > >>>>>> > > >>>>>> Thanks - just one question. Is this starting from the OMG IDL as > > >>>>>> foundation? > > >>>>>> > > >>>>>> I assume so since this was the task to complete. > > >>>>>> > > >>>>>> Best - Thomas > > >>>>>> > > >>>>>> On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: > > >>>>>>> Hi all, > > >>>>>>> > > >>>>>>> as discussed in the last meeting I put here information about our IDL > > >>>>>>> proposal. When final document appears online I will copy this text > > >>>>>>> to it. > > >>>>>>> > > >>>>>>> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar > > >>>>>>> available here: > > >>>>>>> > > >>>>>>> https://thrift.apache.org/docs/idl > > >>>>>>> > > >>>>>>> Our grammar is available here: > > >>>>>>> > > >>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Note: our goal was not to keep a full backwards compatibility with > > >>>>>>> Thrift, but to modify a grammar only when necessary. Still > > >>>>>>> technically > > >>>>>>> we can be backwards compatible (we can parse already *existing* > > >>>>>>> Thrift > > >>>>>>> IDL files), since we avoided to remove any functionality from Thrift > > >>>>>>> (only 'oneway' keyword was removed, see below). However, this was not > > >>>>>>> tested yet. > > >>>>>>> > > >>>>>>> 2. We did following modifications: > > >>>>>>> > > >>>>>>> 2.1 Base types > > >>>>>>> > > >>>>>>> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 > > >>>>>>> > > >>>>>>> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). > > >>>>>>> > > >>>>>>> 'boolean' is used more frequently than 'bool' in other IDLs. We can > > >>>>>>> switch back to 'bool' if desired. > > >>>>>>> > > >>>>>>> 'byte' as a signed integer is not consistent with names of other > > >>>>>>> signed > > >>>>>>> integers (i16, i32, i64). We can switch back to 'byte' as signed > > >>>>>>> 8-bit > > >>>>>>> integer and use 'ubyte' as unsigned 8-bit integer if desired. > > >>>>>>> > > >>>>>>> A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, > > >>>>>>> etc. > > >>>>>>> is here: > > >>>>>>> > > >>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> 2.2 Annotations > > >>>>>>> > > >>>>>>> The official Thirft grammar available on the web (see link above) > > >>>>>>> *does > > >>>>>>> not* contain flexible annotation syntax. There is an annotation > > >>>>>>> support > > >>>>>>> available in the latest Thrift version: > > >>>>>>> > > >>>>>>> https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift > > >>>>>>> > > >>>>>>> > > >>>>>>> However, annotations are limited to key-value pairs and even more > > >>>>>>> important: seems that function arguments and return types can't be > > >>>>>>> annotated, there are at least no examples. > > >>>>>>> > > >>>>>>> Instead of using Thrift annotations we decided to introduce a > > >>>>>>> different > > >>>>>>> syntax inspired by WebIDL: > > >>>>>>> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. > > >>>>>>> > > >>>>>>> 2.2.1 Added syntax for defining custom annotations, similar to > > >>>>>>> structs > > >>>>>>> and exceptions: > > >>>>>>> > > >>>>>>> annotation HTTPPort { > > >>>>>>> i32 port = 80 > > >>>>>>> } > > >>>>>>> > > >>>>>>> 2.2.2 Added ability to annotate following entities: services, service > > >>>>>>> functions, return types of service functions, arguments of service > > >>>>>>> functions. We need this especially for security-related features. For > > >>>>>>> example: > > >>>>>>> > > >>>>>>> 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) > > >>>>>>> } > > >>>>>>> > > >>>>>>> Also see our documentation: > > >>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> 2.3 Generic types > > >>>>>>> > > >>>>>>> Original Thrift IDL supports following predefined container types: > > >>>>>>> list, map, and set. We decided to extend this syntax to > > >>>>>>> arbitrary generic types: GenericType where Ti can be > > >>>>>>> either type or constant. In this way we can support types like > > >>>>>>> bounded > > >>>>>>> arrays but still keep backwards compatibility with the original > > >>>>>>> syntax: > > >>>>>>> > > >>>>>>> array< i32, 2> // bounded array of size 2 > > >>>>>>> array< i32, array< i32, 4> > // two-dimensional array > > >>>>>>> > > >>>>>>> 2.4 Removed Thrift features > > >>>>>>> > > >>>>>>> We removed 'oneway' keyword from Thrift because we can use annotation > > >>>>>>> Oneway: > > >>>>>>> > > >>>>>>> Original Thrift: > > >>>>>>> > > >>>>>>> service Test { > > >>>>>>> oneway void zip() > > >>>>>>> } > > >>>>>>> > > >>>>>>> Our grammar: > > >>>>>>> > > >>>>>>> service Test { > > >>>>>>> [Oneway] void ping() > > >>>>>>> } > > >>>>>>> > > >>>>>>> If backwards-compatibility to Thrift is desired we can try to support > > >>>>>>> both styles. > > >>>>>>> > > >>>>>>> 2.5 Unused Thrift features > > >>>>>>> > > >>>>>>> We currently parse but ignore following Thrift features that are > > >>>>>>> missing > > >>>>>>> in OMG IDL: > > >>>>>>> > > >>>>>>> Struct fields can have optional integer identifier. > > >>>>>>> Struct fields can be 'required' or 'optional'. > > >>>>>>> > > >>>>>>> 2.6 Planned extensions > > >>>>>>> > > >>>>>>> Thrift does not provide entity like CORBA's 'module'. The namespace > > >>>>>>> keyword used by Thrift only allow to specify namespace in the > > >>>>>>> generated > > >>>>>>> code. We plan to add module NAME { ... } entity in order to provide > > >>>>>>> support for nested IDL namespaces as well as annotations per module. > > >>>>>>> > > >>>>>>> Best, > > >>>>>>> > > >>>>>>> Dmitri > > >>>>>>> _______________________________________________ > > >>>>>>> Fiware-middleware mailing list > > >>>>>>> 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 > > > > > > > _______________________________________________ > Fiware-middleware mailing list > Fiware-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/fiware-middleware From dmitri.rubinstein at dfki.de Wed Oct 22 18:32:03 2014 From: dmitri.rubinstein at dfki.de (Dmitri Rubinstein) Date: Wed, 22 Oct 2014 18:32:03 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <1413991083.2352.13.camel@ricardodesktop> References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> <54465440.2090801@zhaw.ch> <54465B87.4060303@gmail.com> <544778CD.6000906@dfki.de> <098b383b5e0949b8bcf840d4109175d8@AM2PR06MB0929.eurprd06.prod.outlook.com> <54477BBD.10505@zhaw.ch> <1413972645.2352.10.camel@ricardodesktop> <1413991083.2352.13.camel@ricardodesktop> Message-ID: <6BB1132F-D4E6-44CC-9496-938F2262EF92@dfki.de> Thank you Ricardo, I not yet fully read the document, but you answered an important question about annotations on return types (I copied it to this mail, see below). When I correctly understand this we can't use the same annotation to mark parameters, return type and the whole operation. So one solution would be to have additionally @OptionallyEncryptedOp annotation in order to avoid a conflict. I can't myself decide if this is OK since the feature for annotating return types was designed especially for CISPA requirements. About annotations in return types of service functions. An annotation has a meaning to the construction it was applied. In the case of an annotation applied in an operation, it can mean something about the operation, or only mean something about its return type. The meaning is defined by creator of the annotation. OMG IDL 4.0 only permits annotation to constructions (service, operation, parameter, etc..), but the return type is not a construction, is only a type. Then, security-related features can be applied to the return type of an operation, using an annotation on the operation. Best Dmitri Am 22. Oktober 2014 17:18:03 MESZ, schrieb Ricardo Gonzalez Moreno : >Hi all, > >I finished the document. I believe I shared the document with >permission >to make comments. Comments are wellcome. > >There is a section about features needed by DFKI. I believe I didn't >forget anything. > >Regards, >Ricardo. > >El mi?, 22-10-2014 a las 10:10 +0000, Ricardo Gonzalez Moreno escribi?: >> Hi all, >> >> I'm working in the document, but it's not finished yet. I need at >> least 4 hours. >> The link of the document is: >> >> >https://docs.google.com/document/d/1Rqi_zwwc-ixdwU9ddAjn83Z24PJP6fpU-Kwhs7wyxOg/edit?usp=sharing >> >> Regards, >> Ricardo >> >> El mi?, 22-10-2014 a las 11:41 +0200, Thomas Michael Bohnert >> escribi?: >> > Jaime, you need to speed up a bit. We had agreed that you provide >> > feedback asap. >> > >> > Thanks, Thomas >> > >> > On 10/22/2014 11:35 AM, Jaime Martin Losa wrote: >> > > Hi Dimitri, >> > > >> > > We will send you soon an updated document about this. Please be >patient. >> > > >> > > Regards, >> > > Jaime. >> > > >> > > -----Original Message----- >> > > From: fiware-middleware-bounces at lists.fi-ware.org >[mailto:fiware-middleware-bounces at lists.fi-ware.org] On Behalf Of >Dmitri Rubinstein >> > > Sent: mi?rcoles, 22 de octubre de 2014 11:29 >> > > To: Thomas Michael Bohnert; Bohnert Thomas Michael (bohe); >fiware-middleware at lists.fi-ware.org >> > > Subject: Re: [Fiware-middleware] DFKI Thrift-based IDL Proposal >> > > >> > > Hi Thomas, >> > > >> > > On 10/21/14 15:11, Thomas Michael Bohnert wrote: >> > >> HI Dimitry, >> > >> >> > >> The starting point will be OMG IDL 3.5. You will sooner or later >have >> > >> to get familiar with it. >> > >> >> > >> Please adhere to that decision and use the time to get into the >topic. >> > >> If you need some more time to study it please let me know. >> > > >> > > Of course I need more time. I received no link to the OMG IDL >spec and found with google this one: >http://www.omg.org/spec/IDL35/3.5/PDF/. It has 100 pages. As far as I >understood we don't plan to support everything, just a subset. But >which parts of the spec ? >> > > >> > > I already found a feature that we can't easily support: >preprocessing (Section 5.3). Since DFKI part of the proposal requires >IDL processing at the runtime of the program it also requires >downloading and parsing of the IDL at the runtime. IDL file with >#include directives can only be correctly preprocessed when all >included files are downloaded in advance. One option is to support only >already preprocessed IDL files without preprocessor directives. >> > > >> > > Best, >> > > >> > > Dmitri >> > > >> > >> >> > >> I will have a look into what you have provided but we will not >start >> > >> from a Thrift foundation. >> > >> >> > >> Thanks for your cooperation, >> > >> Thomas >> > >> >> > >> On 10/21/2014 03:05 PM, Dmitri Rubinstein wrote: >> > >>> Hi Thomas, >> > >>> >> > >>> On 10/21/14 14:40, Thomas Michael Bohnert wrote: >> > >>>> Dimitri, >> > >>>> >> > >>>> Sorry, but then this is beyond was what requested yesterday. >> > >>>> >> > >>>> Thanks for your contribution but we wont consider it.HI >> > >>>> >> > >>>> Please read the minutes again and start from the OMG-IDL 3.5. >> > >>> >> > >>> This is just impossible, since first of all we are not experts >in >> > >>> OMG-IDL. In order to fulfill your task I need not just to see a >OMG-IDL >> > >>> grammar but usage examples for any feature. Thrift provides >them as a >> > >>> part of tutorial and test suite, and I refer to them in my >text. It is >> > >>> hard to me to find similar OMG IDL examples online. >> > >>> >> > >>> Also because of this Philipp requested yesterday a link to the >OMG IDL >> > >>> 3.5 PDF, and I requested answers to my questions regarding >annotation >> > >>> examples. What I mean is when somebody would like to convince >us to use >> > >>> OMG IDL then they should show how our features described in >Thrift IDL >> > >>> will be expressed in OMG IDL. >> > >>> >> > >>> IMHO it does not really matter which spec I use as a foundation >since I >> > >>> describe differences together with examples. Also I documented >features >> > >>> that AFAIK are missing in OMG IDL (2.5 Unused Thrift features) >but are >> > >>> available in Thrift. >> > >>> >> > >>> Best, >> > >>> >> > >>> Dmitri >> > >>> >> > >>>> >> > >>>> Best - Thomas >> > >>>> >> > >>>> On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: >> > >>>>> No, our starting point is Thrift IDL, and I describe all >differences >> > >>>>> including a justification. Task with OMG IDL as foundation is >> > >>>>> eProsima's >> > >>>>> task, since they are experts in OMG IDL. >> > >>>>> >> > >>>>> >https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> Deadline Thu EOB >> > >>>>> Joined document that describes the new IDL >> > >>>>> Features that have been dropped out of OMG (ePros) >> > >>>>> Including a justification >> > >>>>> Features that are proposed by Thrift (DFKI) >> > >>>>> Including a justification >> > >>>>> In particular related to features that are required >by KIARA >> > >>>>> innovations >> > >>>>> >> > >>>>> Best, >> > >>>>> >> > >>>>> Dmitri >> > >>>>> >> > >>>>> On 10/21/14 14:16, Thomas Michael Bohnert wrote: >> > >>>>>> Dimitry, >> > >>>>>> >> > >>>>>> Thanks - just one question. Is this starting from the OMG >IDL as >> > >>>>>> foundation? >> > >>>>>> >> > >>>>>> I assume so since this was the task to complete. >> > >>>>>> >> > >>>>>> Best - Thomas >> > >>>>>> >> > >>>>>> On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: >> > >>>>>>> Hi all, >> > >>>>>>> >> > >>>>>>> as discussed in the last meeting I put here information >about our IDL >> > >>>>>>> proposal. When final document appears online I will copy >this text >> > >>>>>>> to it. >> > >>>>>>> >> > >>>>>>> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the >grammar >> > >>>>>>> available here: >> > >>>>>>> >> > >>>>>>> https://thrift.apache.org/docs/idl >> > >>>>>>> >> > >>>>>>> Our grammar is available here: >> > >>>>>>> >> > >>>>>>> >https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Note: our goal was not to keep a full backwards >compatibility with >> > >>>>>>> Thrift, but to modify a grammar only when necessary. Still >> > >>>>>>> technically >> > >>>>>>> we can be backwards compatible (we can parse already >*existing* >> > >>>>>>> Thrift >> > >>>>>>> IDL files), since we avoided to remove any functionality >from Thrift >> > >>>>>>> (only 'oneway' keyword was removed, see below). However, >this was not >> > >>>>>>> tested yet. >> > >>>>>>> >> > >>>>>>> 2. We did following modifications: >> > >>>>>>> >> > >>>>>>> 2.1 Base types >> > >>>>>>> >> > >>>>>>> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, >u64 >> > >>>>>>> >> > >>>>>>> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). >> > >>>>>>> >> > >>>>>>> 'boolean' is used more frequently than 'bool' in other >IDLs. We can >> > >>>>>>> switch back to 'bool' if desired. >> > >>>>>>> >> > >>>>>>> 'byte' as a signed integer is not consistent with names of >other >> > >>>>>>> signed >> > >>>>>>> integers (i16, i32, i64). We can switch back to 'byte' as >signed >> > >>>>>>> 8-bit >> > >>>>>>> integer and use 'ubyte' as unsigned 8-bit integer if >desired. >> > >>>>>>> >> > >>>>>>> A comparison table for basic types for DFKI/KIARA, CORBA, >Thrift, >> > >>>>>>> etc. >> > >>>>>>> is here: >> > >>>>>>> >> > >>>>>>> >https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> 2.2 Annotations >> > >>>>>>> >> > >>>>>>> The official Thirft grammar available on the web (see link >above) >> > >>>>>>> *does >> > >>>>>>> not* contain flexible annotation syntax. There is an >annotation >> > >>>>>>> support >> > >>>>>>> available in the latest Thrift version: >> > >>>>>>> >> > >>>>>>> >https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> However, annotations are limited to key-value pairs and >even more >> > >>>>>>> important: seems that function arguments and return types >can't be >> > >>>>>>> annotated, there are at least no examples. >> > >>>>>>> >> > >>>>>>> Instead of using Thrift annotations we decided to introduce >a >> > >>>>>>> different >> > >>>>>>> syntax inspired by WebIDL: >> > >>>>>>> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. >> > >>>>>>> >> > >>>>>>> 2.2.1 Added syntax for defining custom annotations, similar >to >> > >>>>>>> structs >> > >>>>>>> and exceptions: >> > >>>>>>> >> > >>>>>>> annotation HTTPPort { >> > >>>>>>> i32 port = 80 >> > >>>>>>> } >> > >>>>>>> >> > >>>>>>> 2.2.2 Added ability to annotate following entities: >services, service >> > >>>>>>> functions, return types of service functions, arguments of >service >> > >>>>>>> functions. We need this especially for security-related >features. For >> > >>>>>>> example: >> > >>>>>>> >> > >>>>>>> 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) >> > >>>>>>> } >> > >>>>>>> >> > >>>>>>> Also see our documentation: >> > >>>>>>> >https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> 2.3 Generic types >> > >>>>>>> >> > >>>>>>> Original Thrift IDL supports following predefined container >types: >> > >>>>>>> list, map, and set. We decided to extend this >syntax to >> > >>>>>>> arbitrary generic types: GenericType where >Ti can be >> > >>>>>>> either type or constant. In this way we can support types >like >> > >>>>>>> bounded >> > >>>>>>> arrays but still keep backwards compatibility with the >original >> > >>>>>>> syntax: >> > >>>>>>> >> > >>>>>>> array< i32, 2> // bounded array of size 2 >> > >>>>>>> array< i32, array< i32, 4> > // two-dimensional array >> > >>>>>>> >> > >>>>>>> 2.4 Removed Thrift features >> > >>>>>>> >> > >>>>>>> We removed 'oneway' keyword from Thrift because we can use >annotation >> > >>>>>>> Oneway: >> > >>>>>>> >> > >>>>>>> Original Thrift: >> > >>>>>>> >> > >>>>>>> service Test { >> > >>>>>>> oneway void zip() >> > >>>>>>> } >> > >>>>>>> >> > >>>>>>> Our grammar: >> > >>>>>>> >> > >>>>>>> service Test { >> > >>>>>>> [Oneway] void ping() >> > >>>>>>> } >> > >>>>>>> >> > >>>>>>> If backwards-compatibility to Thrift is desired we can try >to support >> > >>>>>>> both styles. >> > >>>>>>> >> > >>>>>>> 2.5 Unused Thrift features >> > >>>>>>> >> > >>>>>>> We currently parse but ignore following Thrift features >that are >> > >>>>>>> missing >> > >>>>>>> in OMG IDL: >> > >>>>>>> >> > >>>>>>> Struct fields can have optional integer identifier. >> > >>>>>>> Struct fields can be 'required' or 'optional'. >> > >>>>>>> >> > >>>>>>> 2.6 Planned extensions >> > >>>>>>> >> > >>>>>>> Thrift does not provide entity like CORBA's 'module'. The >namespace >> > >>>>>>> keyword used by Thrift only allow to specify namespace in >the >> > >>>>>>> generated >> > >>>>>>> code. We plan to add module NAME { ... } entity in order to >provide >> > >>>>>>> support for nested IDL namespaces as well as annotations >per module. >> > >>>>>>> >> > >>>>>>> Best, >> > >>>>>>> >> > >>>>>>> Dmitri >> > >>>>>>> _______________________________________________ >> > >>>>>>> Fiware-middleware mailing list >> > >>>>>>> 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 >> > > >> > >> >> _______________________________________________ >> Fiware-middleware mailing list >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dmitri.Rubinstein at dfki.de Thu Oct 23 10:38:25 2014 From: Dmitri.Rubinstein at dfki.de (Dmitri Rubinstein) Date: Thu, 23 Oct 2014 10:38:25 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <6BB1132F-D4E6-44CC-9496-938F2262EF92@dfki.de> References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> <54465440.2090801@zhaw.ch> <54465B87.4060303@gmail.com> <544778CD.6000906@dfki.de> <098b383b5e0949b8bcf840d4109175d8@AM2PR06MB0929.eurprd06.prod.outlook.com> <54477BBD.10505@zhaw.ch> <1413972645.2352.10.camel@ricardodesktop> <1413991083.2352.13.camel@ricardodesktop> <6BB1132F-D4E6-44CC-9496-938F2262EF92@dfki.de> Message-ID: <5448BE81.8040702@dfki.de> For better understanding what I mean here is a better example: // DFKI annotation application [HTTPPort(8080)] service enc { // Function removeString is annotated with // OptionallyEncrypted annotation // without parameters [OptionallyEncrypted] boolean removeString(string fileName) // 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) } Depending on where I put OptionallyEncrypted annotation it applies either to a whole operation, return type, or parameter(s). OMG IDL does not allow me to explicitly annotate return type. In order to provide the same information I need to use two separate annotations, e.g.: @OptionallyEncrypted - return type or function argument is optionally encrypted @OptionallyEncryptedOp - operation is optionally encrypted // OMG IDL 4.0 annotation application @HTTPPort(8080) service enc { // Function removeString is annotated with // OptionallyEncryptedOp annotation // without parameters @OptionallyEncryptedOp boolean removeString(string fileName) // In function saveString Argument s of type string // is annotated with annotation OptionallyEncrypted without // parameters void saveString(string fileName, @OptionallyEncrypted string s) // Operation loadString is annotated with // annotation OptionallyEncrypted without parameters. // This annotation is applied to the return type of the // operation. @OptionallyEncrypted string loadString(string fileName) }; Best, Dmitri On 10/22/14 18:32, Dmitri Rubinstein wrote: > Thank you Ricardo, > > I not yet fully read the document, but you answered an important > question about annotations on return types (I copied it to this mail, > see below). When I correctly understand this we can't use the same > annotation to mark parameters, return type and the whole operation. So > one solution would be to have additionally @OptionallyEncryptedOp > annotation in order to avoid a conflict. I can't myself decide if this > is OK since the feature for annotating return types was designed > especially for CISPA requirements. > > About annotations in return types of service functions. An annotation > has a meaning to the construction it was applied. In the case of an > annotation applied in an operation, it can mean something about the > operation, or only mean something about its return type. The meaning is > defined by creator of the annotation. > OMG IDL 4.0 only permits annotation to constructions (service, > operation, parameter, etc..), but the return type is not a construction, > is only a type. > Then, security-related features can be applied to the return type of an > operation, using an annotation on the operation. > > Best > > Dmitri > > Am 22. Oktober 2014 17:18:03 MESZ, schrieb Ricardo Gonzalez Moreno > : > > Hi all, > > I finished the document. I believe I shared the document with permission > to make comments. Comments are wellcome. > > There is a section about features needed by DFKI. I believe I didn't > forget anything. > > Regards, > Ricardo. > > El mi?, 22-10-2014 a las 10:10 +0000, Ricardo Gonzalez Moreno escribi?: > > Hi all, > > I'm working in the document, but it's not finished yet. I need at > least 4 hours. > The link of the document is: > > https://docs.google.com/document/d/1Rqi_zwwc-ixdwU9ddAjn83Z24PJP6fpU-Kwhs7wyxOg/edit?usp=sharing > > Regards, > Ricardo > > El mi?, 22-10-2014 a las 11:41 +0200, Thomas Michael Bohnert > escrib i?: > > Jaime, you need to speed up a bit. We had agreed that you > provide > feedback asap. > > Thanks, Thomas > > On 10/22/2014 11:35 AM, Jaime Martin Losa wrote: > > Hi Dimitri, > > We will send you soon an updated document about this. > Please be patient. > > Regards, > Jaime. > > -----Original Message----- > From: fiware-middleware-bounces at lists.fi-ware.org > [mailto:fiware-middleware-bounces at lists.fi-ware.org] On > Behalf Of Dmitri Rubinstein > Sent: mi?rcoles, 22 de octubre de 2014 11:29 > To: Thomas Michael Bohnert; Bohnert Thomas Michael > (bohe); fiware-middleware at lists.fi-ware.org > Subject: Re: [Fiware-middleware] DFKI Thrift-based IDL > Proposal > > Hi Thomas, > > On 10/21/14 15:11, Thomas Michael Bohnert wrote: > > HI Dimitry, > > The starting point will be OMG IDL 3.5. You will > sooner or later have > to get familiar with it. > > Please adhere to that decision and use the time to > get into the topic. > If you need some more time to study it please let me > know. > > > Of course I need more time. I received no link to the > OMG IDL spec and found with google this one: > http://www.omg.org/spec/IDL35/3.5/PDF/. It has 100 > pages. As far as I understood we don't plan to support > everything, just a subset. But which parts of the spec ? > > I already found a feature that we can't easily support: > preprocessing (Section 5.3). Since DFKI part of the > proposal requires IDL processing at the runtime of the > program it also requires downl oading and parsing of the > IDL at the runtime. IDL file with #include directives > can only be correctly preprocessed when all included > files are downloaded in advance. One option is to > support only already preprocessed IDL files without > preprocessor directives. > > Best, > > Dmitri > > > I will have a look into what you have provided but > we will not start > from a Thrift foundation. > > Thanks for your cooperation, > Thomas > > On 10/21/2014 03:05 PM, Dmitri Rubinstein wrote: > > Hi Thomas, > > On 10/21/14 14:40, Thomas Michael Bohnert wrote: > > Dimitri, > > Sorry, but then this is beyond was what > requested yesterday. > > Thanks for your contribution but we wont > consider it.HI > > Please read the minutes again and start from > the OMG-IDL 3.5. > > > This is just impossible, since first of all we > are not experts in > OMG-IDL. In order to fulfill your task I need > not just to see a OMG-IDL > grammar but usage examples for any feature. > Thrift provides them as a > part of tutorial and test suite, and I refer to > them in my text. It is > hard to me to find similar OMG IDL examples online. > > Also because of this Philipp requested yesterday > a link to the OMG IDL > 3.5 PDF, and I requested answers to my questions > regarding annotation > examples. What I mean is when somebody would > like to convince us to use > OMG IDL then they should show how our features > described in Thrift IDL > will be expressed in OMG IDL. > > IMHO it does not really matter which spec I use > as a foundati on since I > describe differences together with examples. > Also I documented features > that AFAIK are missing in OMG IDL (2.5 Unused > Thrift features) but are > available in Thrift. > > Best, > > Dmitri > > > Best - Thomas > > On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: > > No, our starting point is Thrift IDL, > and I describe all differences > including a justification. Task with OMG > IDL as foundation is > eProsima's > task, since they are experts in OMG IDL. > > https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: > > > > Deadline Th u EOB > Joined document that describes the new IDL > Features that have been dropped out of > OMG (ePros) > Including a justification > Features that are proposed by Thrift (DFKI) > Including a justification > In particular related to features that > are required by KIARA > innovations > > Best, > > Dmitri > > On 10/21/14 14:16, Thomas Michael > Bohnert wrote: > > Dimitry, > > Thanks - just one question. Is this > starting from the OMG IDL as > foundation? > > I assume so since this was the task > to complete. > > Best - Thomas > > On 10/21/2014 02:13 PM, Dmitri > Rubinstein wrote: > > Hi all, > > as discussed in the last me > eting I put here information > about our IDL > proposal. When final document > appears online I will copy this text > to it. > > 1. KIARA/DFKI IDL is based on > Apache Thrift IDL, with the grammar > available here: > > https://thrift.apache.org/docs/idl > > Our grammar is available here: > > https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language > > > > > Note: our goal was not to keep a > full backwards compatibility with > Thrift, but to modify a grammar > only when necessary. Still > technically > we can be backwards compatible > (we can parse already *existing* > Thrift > IDL files), since we avoided to > remove any functionality from Thrift > (only 'oneway' keyword was > removed, see below). However, > this was not > tested yet. > > 2. We did following modifications: > > 2.1 Base types > > 2.1.1 Added unsigned types > missing in Thrift: u8, u16, u32, u64 > > 2.1.2 Renamed bool to boolean, > byte to i8 (signed byte). > > 'boolean' is used more > frequently than 'bool' in other > IDLs. We can > switch back to 'bool' if desired. > > 'byte' as a signed integer is > not consistent with names of other > signed > integers (i16, i32, i64). We can > switch back to 'byte' as signed > 8-bit > integer and use 'ubyte' as > unsigned 8-bit integer if desired. > > A comparison table for basic > types for DFKI/KIARA, CORBA, Thrift, > etc. > is here: > > https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types > > > > > 2.2 Annotations > > The official Thirft grammar > available on the web (see link > above) > *does > not* contain flexible annotation > syntax. There is an annotation > support > available in the latest Thrift > version: > > https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift > > > However, annotations are limited > to key-value pairs and even more > important: seems that function > arguments and return types can't be > annotated, there are at least no > examples. > > Instead of using Thrift > annotations we decided to > introduce a > different > syntax inspired by WebIDL: > http://www.w3.org/TR/WebIDL/#idl-extended-attributes. > > 2.2.1 Added syntax for defining > custom annotations, similar to > structs > and exceptions: > > annotation HTTPPort { > i32 port = 80 > } > > 2.2.2 Added ability to annotate > following entities: services, > service > functions, return types of > service functions, arguments of > service > functions. We need this > especially for security-related > features. For > example: > > 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 save String > 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) > } > > Also see our documentation: > https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 > > > > > 2.3 Generic types > > Original Thrift IDL supports > following predefined container > types: > list, map, and set. > We decided to extend this syntax to > arbitrary generic types: > GenericType > where Ti can be > either type or constant. In this > way we can support types like > bounded > arrays but still keep backwards > compatibility with the original > syntax: > > array< i32, 2> // bounded array > of size 2 > array< i32, array< i32, 4> > // > two-dimensional array > > 2.4 Removed Thrift features > > We removed 'oneway' keyword from > Thrift because we can use annotation > Oneway: > > Original Thrift: > > service Test { > oneway void zip() > } > > Our grammar: > > service Test { > [Oneway] void ping() > } > > If backwards-compatibility to > Thrift is desired we can try to > support > both styles. > > 2.5 Unused Thrift features > > We currently parse but ignore > following Thrift features that are > missing > in OMG IDL: > > Struct fields can have option al > integer identifier. > Struct fields can be 'required' > or 'optional'. > > 2.6 Planned extensions > > Thrift does not provide entity > like CORBA's 'module'. The namespace > keyword used by Thrift only > allow to specify namespace in the > generated > code. We plan to add module NAME > { ... } entity in order to provide > support for nested IDL > namespaces as well as > annotations per module. > > Best, > > Dmitri > ------------------------------------------------------------------------ > > Fiware-middleware mailing list > 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 > > > > > ------------------------------------------------------------------------ > > Fiware-middleware mailing list > 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 > > > > _______________________________________________ > Fiware-middleware mailing list > Fiware-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/fiware-middleware > From Dmitri.Rubinstein at dfki.de Thu Oct 23 15:00:19 2014 From: Dmitri.Rubinstein at dfki.de (Dmitri Rubinstein) Date: Thu, 23 Oct 2014 15:00:19 +0200 Subject: [Fiware-middleware] DFKI Thrift-based IDL Proposal In-Reply-To: <1413991083.2352.13.camel@ricardodesktop> References: <54464E9E.9080105@zhaw.ch> <8d7156d42ca146f8ac6fb7855bc94a4f@SRV-MAIL-001.zhaw.ch> <54465440.2090801@zhaw.ch> <54465B87.4060303@gmail.com> <544778CD.6000906@dfki.de> <098b383b5e0949b8bcf840d4109175d8@AM2PR06MB0929.eurprd06.prod.outlook.com> <54477BBD.10505@zhaw.ch> <1413972645.2352.10.camel@ricardodesktop> <1413991083.2352.13.camel@ricardodesktop> Message-ID: <5448FBE3.9080902@dfki.de> I think I commented all issues that I found including possible resolutions. Best, Dmitri On 10/22/14 17:18, Ricardo Gonzalez Moreno wrote: > Hi all, > > I finished the document. I believe I shared the document with permission > to make comments. Comments are wellcome. > > There is a section about features needed by DFKI. I believe I didn't > forget anything. > > Regards, > Ricardo. > > El mi?, 22-10-2014 a las 10:10 +0000, Ricardo Gonzalez Moreno escribi?: >> Hi all, >> >> I'm working in the document, but it's not finished yet. I need at >> least 4 hours. >> The link of the document is: >> >> https://docs.google.com/document/d/1Rqi_zwwc-ixdwU9ddAjn83Z24PJP6fpU-Kwhs7wyxOg/edit?usp=sharing >> >> Regards, >> Ricardo >> >> El mi?, 22-10-2014 a las 11:41 +0200, Thomas Michael Bohnert >> escribi?: >>> Jaime, you need to speed up a bit. We had agreed that you provide >>> feedback asap. >>> >>> Thanks, Thomas >>> >>> On 10/22/2014 11:35 AM, Jaime Martin Losa wrote: >>>> Hi Dimitri, >>>> >>>> We will send you soon an updated document about this. Please be patient. >>>> >>>> Regards, >>>> Jaime. >>>> >>>> -----Original Message----- >>>> From: fiware-middleware-bounces at lists.fi-ware.org [mailto:fiware-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri Rubinstein >>>> Sent: mi?rcoles, 22 de octubre de 2014 11:29 >>>> To: Thomas Michael Bohnert; Bohnert Thomas Michael (bohe); fiware-middleware at lists.fi-ware.org >>>> Subject: Re: [Fiware-middleware] DFKI Thrift-based IDL Proposal >>>> >>>> Hi Thomas, >>>> >>>> On 10/21/14 15:11, Thomas Michael Bohnert wrote: >>>>> HI Dimitry, >>>>> >>>>> The starting point will be OMG IDL 3.5. You will sooner or later have >>>>> to get familiar with it. >>>>> >>>>> Please adhere to that decision and use the time to get into the topic. >>>>> If you need some more time to study it please let me know. >>>> >>>> Of course I need more time. I received no link to the OMG IDL spec and found with google this one: http://www.omg.org/spec/IDL35/3.5/PDF/. It has 100 pages. As far as I understood we don't plan to support everything, just a subset. But which parts of the spec ? >>>> >>>> I already found a feature that we can't easily support: preprocessing (Section 5.3). Since DFKI part of the proposal requires IDL processing at the runtime of the program it also requires downloading and parsing of the IDL at the runtime. IDL file with #include directives can only be correctly preprocessed when all included files are downloaded in advance. One option is to support only already preprocessed IDL files without preprocessor directives. >>>> >>>> Best, >>>> >>>> Dmitri >>>> >>>>> >>>>> I will have a look into what you have provided but we will not start >>>>> from a Thrift foundation. >>>>> >>>>> Thanks for your cooperation, >>>>> Thomas >>>>> >>>>> On 10/21/2014 03:05 PM, Dmitri Rubinstein wrote: >>>>>> Hi Thomas, >>>>>> >>>>>> On 10/21/14 14:40, Thomas Michael Bohnert wrote: >>>>>>> Dimitri, >>>>>>> >>>>>>> Sorry, but then this is beyond was what requested yesterday. >>>>>>> >>>>>>> Thanks for your contribution but we wont consider it.HI >>>>>>> >>>>>>> Please read the minutes again and start from the OMG-IDL 3.5. >>>>>> >>>>>> This is just impossible, since first of all we are not experts in >>>>>> OMG-IDL. In order to fulfill your task I need not just to see a OMG-IDL >>>>>> grammar but usage examples for any feature. Thrift provides them as a >>>>>> part of tutorial and test suite, and I refer to them in my text. It is >>>>>> hard to me to find similar OMG IDL examples online. >>>>>> >>>>>> Also because of this Philipp requested yesterday a link to the OMG IDL >>>>>> 3.5 PDF, and I requested answers to my questions regarding annotation >>>>>> examples. What I mean is when somebody would like to convince us to use >>>>>> OMG IDL then they should show how our features described in Thrift IDL >>>>>> will be expressed in OMG IDL. >>>>>> >>>>>> IMHO it does not really matter which spec I use as a foundation since I >>>>>> describe differences together with examples. Also I documented features >>>>>> that AFAIK are missing in OMG IDL (2.5 Unused Thrift features) but are >>>>>> available in Thrift. >>>>>> >>>>>> Best, >>>>>> >>>>>> Dmitri >>>>>> >>>>>>> >>>>>>> Best - Thomas >>>>>>> >>>>>>> On 10/21/2014 02:26 PM, Dmitri Rubinstein wrote: >>>>>>>> No, our starting point is Thrift IDL, and I describe all differences >>>>>>>> including a justification. Task with OMG IDL as foundation is >>>>>>>> eProsima's >>>>>>>> task, since they are experts in OMG IDL. >>>>>>>> >>>>>>>> https://docs.google.com/document/d/1a0pttnIaHX6aGvCqvostEm8iB1n1hHD7vg7JxbfNe5Y/edit: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Deadline Thu EOB >>>>>>>> Joined document that describes the new IDL >>>>>>>> Features that have been dropped out of OMG (ePros) >>>>>>>> Including a justification >>>>>>>> Features that are proposed by Thrift (DFKI) >>>>>>>> Including a justification >>>>>>>> In particular related to features that are required by KIARA >>>>>>>> innovations >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Dmitri >>>>>>>> >>>>>>>> On 10/21/14 14:16, Thomas Michael Bohnert wrote: >>>>>>>>> Dimitry, >>>>>>>>> >>>>>>>>> Thanks - just one question. Is this starting from the OMG IDL as >>>>>>>>> foundation? >>>>>>>>> >>>>>>>>> I assume so since this was the task to complete. >>>>>>>>> >>>>>>>>> Best - Thomas >>>>>>>>> >>>>>>>>> On 10/21/2014 02:13 PM, Dmitri Rubinstein wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> as discussed in the last meeting I put here information about our IDL >>>>>>>>>> proposal. When final document appears online I will copy this text >>>>>>>>>> to it. >>>>>>>>>> >>>>>>>>>> 1. KIARA/DFKI IDL is based on Apache Thrift IDL, with the grammar >>>>>>>>>> available here: >>>>>>>>>> >>>>>>>>>> https://thrift.apache.org/docs/idl >>>>>>>>>> >>>>>>>>>> Our grammar is available here: >>>>>>>>>> >>>>>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#KIARA_Interface_definition_language >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Note: our goal was not to keep a full backwards compatibility with >>>>>>>>>> Thrift, but to modify a grammar only when necessary. Still >>>>>>>>>> technically >>>>>>>>>> we can be backwards compatible (we can parse already *existing* >>>>>>>>>> Thrift >>>>>>>>>> IDL files), since we avoided to remove any functionality from Thrift >>>>>>>>>> (only 'oneway' keyword was removed, see below). However, this was not >>>>>>>>>> tested yet. >>>>>>>>>> >>>>>>>>>> 2. We did following modifications: >>>>>>>>>> >>>>>>>>>> 2.1 Base types >>>>>>>>>> >>>>>>>>>> 2.1.1 Added unsigned types missing in Thrift: u8, u16, u32, u64 >>>>>>>>>> >>>>>>>>>> 2.1.2 Renamed bool to boolean, byte to i8 (signed byte). >>>>>>>>>> >>>>>>>>>> 'boolean' is used more frequently than 'bool' in other IDLs. We can >>>>>>>>>> switch back to 'bool' if desired. >>>>>>>>>> >>>>>>>>>> 'byte' as a signed integer is not consistent with names of other >>>>>>>>>> signed >>>>>>>>>> integers (i16, i32, i64). We can switch back to 'byte' as signed >>>>>>>>>> 8-bit >>>>>>>>>> integer and use 'ubyte' as unsigned 8-bit integer if desired. >>>>>>>>>> >>>>>>>>>> A comparison table for basic types for DFKI/KIARA, CORBA, Thrift, >>>>>>>>>> etc. >>>>>>>>>> is here: >>>>>>>>>> >>>>>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Primitive_types >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2.2 Annotations >>>>>>>>>> >>>>>>>>>> The official Thirft grammar available on the web (see link above) >>>>>>>>>> *does >>>>>>>>>> not* contain flexible annotation syntax. There is an annotation >>>>>>>>>> support >>>>>>>>>> available in the latest Thrift version: >>>>>>>>>> >>>>>>>>>> https://github.com/apache/thrift/blob/master/test/AnnotationTest.thrift >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> However, annotations are limited to key-value pairs and even more >>>>>>>>>> important: seems that function arguments and return types can't be >>>>>>>>>> annotated, there are at least no examples. >>>>>>>>>> >>>>>>>>>> Instead of using Thrift annotations we decided to introduce a >>>>>>>>>> different >>>>>>>>>> syntax inspired by WebIDL: >>>>>>>>>> http://www.w3.org/TR/WebIDL/#idl-extended-attributes. >>>>>>>>>> >>>>>>>>>> 2.2.1 Added syntax for defining custom annotations, similar to >>>>>>>>>> structs >>>>>>>>>> and exceptions: >>>>>>>>>> >>>>>>>>>> annotation HTTPPort { >>>>>>>>>> i32 port = 80 >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> 2.2.2 Added ability to annotate following entities: services, service >>>>>>>>>> functions, return types of service functions, arguments of service >>>>>>>>>> functions. We need this especially for security-related features. For >>>>>>>>>> example: >>>>>>>>>> >>>>>>>>>> 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) >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Also see our documentation: >>>>>>>>>> https://forge.fi-ware.org/plugins/mediawiki/wiki/fi-ware-private/index.php/Middleware_-_KIARA_-_User_and_Programmers_Guide#Functions_2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2.3 Generic types >>>>>>>>>> >>>>>>>>>> Original Thrift IDL supports following predefined container types: >>>>>>>>>> list, map, and set. We decided to extend this syntax to >>>>>>>>>> arbitrary generic types: GenericType where Ti can be >>>>>>>>>> either type or constant. In this way we can support types like >>>>>>>>>> bounded >>>>>>>>>> arrays but still keep backwards compatibility with the original >>>>>>>>>> syntax: >>>>>>>>>> >>>>>>>>>> array< i32, 2> // bounded array of size 2 >>>>>>>>>> array< i32, array< i32, 4> > // two-dimensional array >>>>>>>>>> >>>>>>>>>> 2.4 Removed Thrift features >>>>>>>>>> >>>>>>>>>> We removed 'oneway' keyword from Thrift because we can use annotation >>>>>>>>>> Oneway: >>>>>>>>>> >>>>>>>>>> Original Thrift: >>>>>>>>>> >>>>>>>>>> service Test { >>>>>>>>>> oneway void zip() >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Our grammar: >>>>>>>>>> >>>>>>>>>> service Test { >>>>>>>>>> [Oneway] void ping() >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> If backwards-compatibility to Thrift is desired we can try to support >>>>>>>>>> both styles. >>>>>>>>>> >>>>>>>>>> 2.5 Unused Thrift features >>>>>>>>>> >>>>>>>>>> We currently parse but ignore following Thrift features that are >>>>>>>>>> missing >>>>>>>>>> in OMG IDL: >>>>>>>>>> >>>>>>>>>> Struct fields can have optional integer identifier. >>>>>>>>>> Struct fields can be 'required' or 'optional'. >>>>>>>>>> >>>>>>>>>> 2.6 Planned extensions >>>>>>>>>> >>>>>>>>>> Thrift does not provide entity like CORBA's 'module'. The namespace >>>>>>>>>> keyword used by Thrift only allow to specify namespace in the >>>>>>>>>> generated >>>>>>>>>> code. We plan to add module NAME { ... } entity in order to provide >>>>>>>>>> support for nested IDL namespaces as well as annotations per module. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> >>>>>>>>>> Dmitri >>>>>>>>>> _______________________________________________ >>>>>>>>>> Fiware-middleware mailing list >>>>>>>>>> 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 >>>> >>> >> >> _______________________________________________ >> Fiware-middleware mailing list >> 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 > From JaimeMartin at eprosima.com Fri Oct 24 13:02:38 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Fri, 24 Oct 2014 11:02:38 +0000 Subject: [Fiware-middleware] The hangout link Message-ID: https://plus.google.com/hangouts/_/g63czw4jtore5rb4a4btrjz7tqa Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFEF8A.C96C0A60] The Middleware Experts Phone: + 34 91 804 34 48 / + 34 607 91 37 45 JaimeMartin at eProsima.com www.eProsima.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3800 bytes Desc: image001.png URL: From JaimeMartin at eprosima.com Fri Oct 24 14:00:36 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Fri, 24 Oct 2014 12:00:36 +0000 Subject: [Fiware-middleware] KIARA API Discussion Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1490 bytes Desc: not available URL: From JaimeMartin at eprosima.com Tue Oct 28 14:04:59 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Tue, 28 Oct 2014 13:04:59 +0000 Subject: [Fiware-middleware] KIARA API Discussion Message-ID: <55f750fecbe842b48cbd98e9036a3ec0@AM2PR06MB0929.eurprd06.prod.outlook.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1490 bytes Desc: not available URL: From RicardoGonzalez at eprosima.com Thu Oct 30 15:07:41 2014 From: RicardoGonzalez at eprosima.com (Ricardo Gonzalez Moreno) Date: Thu, 30 Oct 2014 14:07:41 +0000 Subject: [Fiware-middleware] Link to document Message-ID: <1414678055.22785.4.camel@ricardodesktop> Hi all, Here is the link to the document about KIARA API with URLs or object references. https://docs.google.com/document/d/1Z3CKAWBxyS6etzLXXToqqdk9udaxa83dNXbqvZqy1NU/edit?usp=sharing Best regards, Ricardo. From philipp.slusallek at dfki.de Thu Oct 30 15:09:13 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Thu, 30 Oct 2014 15:09:13 +0100 Subject: [Fiware-middleware] Call? Message-ID: <54524689.9070808@dfki.de> Hi, Are we having a call now as announced? Best, Philipp -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From RicardoGonzalez at eprosima.com Thu Oct 30 15:09:11 2014 From: RicardoGonzalez at eprosima.com (Ricardo Gonzalez Moreno) Date: Thu, 30 Oct 2014 14:09:11 +0000 Subject: [Fiware-middleware] Hangout link Message-ID: <1414678136.22785.5.camel@ricardodesktop> https://plus.google.com/hangouts/_/g5ld3vuhnbgsk3fqtf5kakpcjua From JaimeMartin at eprosima.com Thu Oct 30 15:11:09 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Thu, 30 Oct 2014 14:11:09 +0000 Subject: [Fiware-middleware] Call? In-Reply-To: <54524689.9070808@dfki.de> References: <54524689.9070808@dfki.de> Message-ID: <5925e948dfa14b7f9298b2cbadd5aa48@AM2PR06MB0929.eurprd06.prod.outlook.com> https://docs.google.com/document/d/1Z3CKAWBxyS6etzLXXToqqdk9udaxa83dNXbqvZqy1NU/edit?usp=sharing Regards, Jaime. -----Original Message----- From: fiware-middleware-bounces at lists.fi-ware.org [mailto:fiware-middleware-bounces at lists.fi-ware.org] On Behalf Of Philipp Slusallek Sent: jueves, 30 de octubre de 2014 15:09 To: fiware-middleware at lists.fi-ware.org Subject: [Fiware-middleware] Call? Hi, Are we having a call now as announced? Best, Philipp -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4040/8397 - Release Date: 10/16/14 Internal Virus Database is out of date. ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4040/8397 - Release Date: 10/16/14 Internal Virus Database is out of date. From RicardoGonzalez at eprosima.com Fri Oct 31 11:58:57 2014 From: RicardoGonzalez at eprosima.com (Ricardo Gonzalez Moreno) Date: Fri, 31 Oct 2014 10:58:57 +0000 Subject: [Fiware-middleware] Documentation updated Message-ID: <1414753137.22785.15.camel@ricardodesktop> Hi all, I update the eProsima proposal in the common document that Christof created. There were changes, adding ZHAW and DFKI suggestions, and trying to be compatible with future RPC over DDS standard. Yesterday at night Jaime and me were in a meeting with RTI about this standard. I wrote this in the common document in order to you will be able to start looking at it. But I'm waiting Jaime for an internal revision of this. Thanks. Ricardo. From JaimeMartin at eprosima.com Fri Oct 31 13:05:41 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Fri, 31 Oct 2014 12:05:41 +0000 Subject: [Fiware-middleware] hang out link Message-ID: <2ff104ead3be4d08a9db55c0063f1771@AM2PR06MB0929.eurprd06.prod.outlook.com> https://plus.google.com/hangouts/_/gswntqf2vfae2lk6f75icphjrea Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFF50B.1D864D60] The Middleware Experts Phone: + 34 91 804 34 48 / + 34 607 91 37 45 JaimeMartin at eProsima.com www.eProsima.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3800 bytes Desc: image001.png URL: From JaimeMartin at eprosima.com Fri Oct 31 14:26:47 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Fri, 31 Oct 2014 13:26:47 +0000 Subject: [Fiware-middleware] KIARA API Discussion Message-ID: <2b7a900bb72f4633b847d7a243908e0a@AM2PR06MB0929.eurprd06.prod.outlook.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1490 bytes Desc: not available URL: