Hello,

   Imagine a small company that would like to implement, for example, an Ada client API for ROS.  What would this small company have to do in order to find out how their new ROS Ada client API must behave?

best regards,
-andrew


On Tue, Feb 18, 2014 at 8:43 PM, William Woodall <william@osrfoundation.org> wrote:
Sorry that entirely wrong, Michi Henning is chief scientist at ZeroC (which makes the Ice middleware). Martin Sústrik is the developer of ZeroMQ and nanomsg. Sorry about that :/.

Still an interesting point.


On Tue, Feb 18, 2014 at 5:40 PM, William Woodall <william@osrfoundation.org> wrote:
This article was very good:


I think that is outlines many of the fears that one might have with DDS, culturally, but we should keep in mind that it is describing CORBA. Part of me hopes that OMG learned from this with DDS and that the history of DDS is different enough to avoid some of the mistakes CORBA made. It is definitely something we will keep an eye on as we do market research and during our prototyping.

A very interesting point is that this article was written by Michi Henning, the chief architect of ZeroMQ, who as since moved on to nanomsg. Such a small world :)


On Sat, Feb 15, 2014 at 3:19 PM, Michael Zillich <zillich@acin.tuwien.ac.at> wrote:
Hi,

my two cents regarding this discussion come from experiences with another "industry-standard" middleware, that was somewhat ... complex internally and thus typically was hidden under layers of convenience code: the abominable CORBA.
(I ended up writing my own middleware after CORBA nearly killed a project)

I have to admit I know nothing about DDS, so forgive me if I unjustly critizise it. But reading in some of the ongoing discussions that its complexity can easily be handled by some abstraction layer .. that rang an alarm bell.

If something is too complex to use for the intended target audience of developers, and thus has to be hidden behind another layer (which, trust me, inevitably leads to the most hilarious bugs you can possibly imagine) then it is probably the wrong technology for that application area. (But there are certainly other appliction areas where this middleware is the perfect choice).

So my personal choice is always a clear and simple solution targeted at a specific application area (with specific requirements, problems, and development procedures and cycles) rather than a solves-all-and-everyones-problems solution developled by large committees.

cheers,
Michael

p.s. For those interested in the CORBA story read the enlightening article by Michi Henning
  https://queue.acm.org/detail.cfm?id=1142044
who as one of the authors of "Advanced CORBA Programming with C++" is probably one of the only two persons on the planet, who actually understood CORBA (the other person being Steve Vinoski, the other author of the book).

--
Dr. Michael Zillich
ACIN Institute of Automation and Control
Vienna University of Technology
(DVR-Number 0005886)
Gusshausstr 27-29/E376, 1040 Vienna, Austria
zillich@acin.tuwien.ac.at       http://users.acin.tuwien.ac.at/mzillich
Tel: +43 1 58801 376648           Fax: +43 1 58801 37698

_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users



--
William Woodall
ROS Development Team



--
William Woodall
ROS Development Team

_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users