[Miwi-middleware] New date for the meeting: Tomorrow, Tuesday at 9.00

[Philipp Slusallek]

Hi,

Unfortunately, I am booked also today, but cannot change this given the
short notice. Dmitri will be at the meeting, though.

I am a bit surprised that we did not get any feedback to our proposals
and also no rational for the one from ePros. It is a bit difficult to
discuss the different proposals, if key information about their design
are not known and we do not get any information or discussion going
about the specific merits of each one of them. This delays the selection
of the new API, which I understood should be done quickly. I suggest we
move to a more agile discussion.

We could already have done most of that by email with everyone's
participation, instead of trying to do this in telcos where
participation is more difficult. Can I at least ask for a detailed
documentation of the answers and feedback that will hopefully be
provided today. We need to thoroughly document them anyway, as this is a
key input for the reviewer who is supposed to look at this (to we have
more info on that by now, yet?).

Let me give you my (preliminary) feedback on the current state of the
proposals:

-- IDL: I fail to see the benefits of the new mixed IDL. It has mainly
the same features of Thrift, which is widely used. Making it
incompatible without a major benefit seems not a good idea. So I would
argue for using the basic Thrift IDL to remain compatible with other
uses and only add features where this may be required for new functionality.

-- API: Again I fail to see the advantage of the app managing the
communication setup. This is exactly the type of detail that an
application should not be concerned with. All it should deal with is a
"reference" or "name" of a service, which may encode also its location
for the most simple cases as discussed here. When the app manages this
aspect, all the details of the network setup are encoded in the app and
its is hard to update and improve the middleware without rewriting the app.

Furthermore, the suggested API is not scalable as we have discussed and
I see no option for including security or the app-derived extension into
it without conceptually changing how the app interacts with the
middleware. As there are other options available, which even simplify
the API with respect to the connection setup, I see so reason, why we
should go in that direction. Not rational has been provided for that either.

The proposed API is functionally almost identical to the one of Thrift
but just different. I do not see a reason to do that either, if (for
whatever reason) one wants to do a non-scalable API at all.

I will be happy to comment on Christof's proposal as soon as I get a
chance to see it.


Best,

	Philipp


Am 06.10.2014 um 09:05 schrieb Jaime Martin Losa:
>                 Hi guys,
> 
>                 Given DFKI cannot attend, we postpone the meeting until tomorrow. In the meantime:
> 
> 1.- Christof is going to send his proposal (almost finished right now)
> 2.- We will answer the Dmitri's questions.
> 
> Regards,
> Jaime Martin Losa
> CEO
> Twitter: @JaimeMartinLosa<https://twitter.com/JaimeMartinLosa>
> 
> [cid:image001.png at 01CFE144.9C3309D0]
> The Middleware Experts
> 
> Phone: + 34 91 804 34 48 /
> + 34 607 91 37 45
> JaimeMartin at eProsima.com<mailto:JaimeMartin at eProsima.com>
> www.eProsima.com<http://www.eprosima.com/>
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Miwi-middleware mailing list
> Miwi-middleware at lists.fi-ware.org
> https://lists.fi-ware.org/listinfo/miwi-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: <https://lists.fiware.org/private/miwi-middleware/attachments/20141007/ba05af17/attachment.vcf>