Here are my comments and questions to your proposal: 1. IDL is a hybrid of OMG IDL and Thrift as you explain, however I miss an explanation why you added some features and removed others. Also besides the grammar, some examples of added/removed features would be very helpful. a) I found no syntax for annotations in your grammar, but we need them for security. We need annotations for services, service operations, return types and operation arguments. b) Why do we need separate types wstring and string like in CORBA, Thrift just use string. c) Do we need strings with limited length (<string_type>) ? d) Why do you prefer CORBA's notation for integers (long, short, unsigned long, etc.) to Thrift's (i32, i16, u32, etc.). Thrift's syntax directly tells you the minimal number of bits that you require to represent the value. f) You propose data types list<T> and arrays id[n][m]... (<array_declarator>). Is the difference in the mapping to Java ? Why do we need two different syntax styles, why not array<T> and array<T, Length> instead ? 2. API First, I need to say that we have a similar two layer API in our KIARA/DFKI Java implementation: Transport - factory that produces TransportConnection and TransportAddress instances TransportConnection - a single connection between client and server. TransportAddress - abstract address identifying TransportConnection, Transport can construct TransportAddress from URI. ProtocolRegistry - factory that provides registration of Protocol classes, and construction of Protocol instances. Protocol - provides construction of Message instances for requests and responses from data (ByteBuffer). However, we use this API only internally. Of course we can provide RPC functionality like you suggest by making these two layers public. But then when we provide a new functionality like negotation or new protocols or serializers user of our library will need to take care of correct construction and initialization of all the required components (negotation layer, transport, serialization, etc). For example when we provide a new protocol, user will need to modify code of his application (client and server) in order to use it. Likely he will try to overcome this scalability limitation by writing a lot of boilerplate code for configuration, and finally will move his code into a separate library with a simpler API on top of ours. What we propose is to avoid "boilerplate" code. In our opinion user should not take care about how exactly connection is created, which transport and serialization is used but instead he should just tell 'connect me to endpoint with the specified URI' and our library should do the rest. And finally when the API is working nearly exactly like the one Thrift already provides, why not to just use Thrift and extend it ? Best, Dmitri On 10/03/14 13:16, Ricardo Gonzalez Moreno wrote: > Hi all, > > I've attached the eProsima initial submission. > > Best regards, > Ricardo > > > El vie, 03-10-2014 a las 10:59 +0000, Jaime Martin Losa escribió: >> HI everyone, I am going to let you work during the >> weekend to complete the submissions you own me. >> >> >> >> We will send our submission in a few minutes. >> >> >> >> Discussion and voting next Monday. >> >> >> >> Not KIARA meeting today. >> >> >> >> Regards, >> >> Jaime Martin Losa >> >> CEO >> >> Twitter:@JaimeMartinLosa >> >> >> >> >> The Middleware Experts >> >> >> Phone: + 34 91 804 34 48 / >> >> + 34 607 91 37 45 >> >> JaimeMartin at eProsima.com >> >> www.eProsima.com >> >> >> >> >> >> >> >> >> _______________________________________________ >> Miwi-middleware mailing list >> Miwi-middleware at lists.fi-ware.org >> https://lists.fi-ware.org/listinfo/miwi-middleware > > > > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware >
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy