<div dir="ltr">Sorry if I was unclear. I meant that ROS Services, as implemented, are an antipattern in terms of abstraction inversion, that they don't expose enough functionally really needed to do proper communication of that sort. Furthermore, it hides the sorts of design choices which should be made explicit by the user. For example, the user should specify whether they want to block or not. Also, communication failures, thread failures, preemptions, and voluntary function errors should all be explicitly distinguished, as actionlib does for the most part.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 6:43 AM, Christian Schlegel <span dir="ltr"><<a href="mailto:schlegel@hs-ulm.de" target="_blank">schlegel@hs-ulm.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>be careful: "ROS services" is not the sane as "service-oriented" as in the meaning of SOA (I mean communication patterns in the line of SOA and *not* in the sense of ROS services)</div>
<div><br></div><div>Christian<br><br><div>---</div>Prof. Dr. Christian Schlegel<div>Prodekan, Studiendekan Master IS</div><div>Fakultät Informatik</div><div>Hochschule Ulm</div><div><br></div><div>Tel.: 0731 / 50-28242</div>
<div><br></div><div><a href="http://www.hs-ulm.de/schlegel" target="_blank">http://www.hs-ulm.de/schlegel</a></div><div><a href="http://www.zafh-servicerobotik.de/" target="_blank">http://www.zafh-servicerobotik.de/</a></div>
<div><a href="http://www.youtube.com/user/roboticsathsulm" target="_blank">http://www.youtube.com/user/roboticsathsulm</a></div><div><a href="http://smart-robotics.sourceforge.net/" target="_blank">http://smart-robotics.sourceforge.net/</a></div>
<div><a href="http://www.joser.org/" target="_blank">http://www.joser.org/</a></div></div><div><br>Am 18.02.2014 um 12:37 schrieb "Kelsey Hawkins" <<a href="mailto:kphawkins@gmail.com" target="_blank">kphawkins@gmail.com</a>>:<br>
<br></div><div><div class="h5"><blockquote type="cite"><div><div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><p dir="ltr">but in my personal opinion, services are a bad idea anyway, and what we really want is something more like (though not necessarily exactly the same) what actionlib offers</p>
</blockquote>
<p dir="ltr">I wholeheartedly agree and might go so far as to call it an antipattern. I feel it overly simplifies synchronous communication, making many nodes more fragile. I'd be happy to see something like actionlib replace services entirely.</p>
<p>-Kelsey<br></p><div class="gmail_quote">On Feb 18, 2014 3:42 AM, "Ingo Lütkebohle" <<a href="mailto:iluetkeb@gmail.com" target="_blank">iluetkeb@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">On Tue, Feb 18, 2014 at 2:12 AM, Brian Gerkey <span dir="ltr"><<a href="mailto:gerkey@osrfoundation.org" target="_blank">gerkey@osrfoundation.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Mon, Feb 17, 2014 at 9:06 AM, Wrede, Sebastian<br>
<<a href="mailto:swrede@techfak.uni-bielefeld.de" target="_blank">swrede@techfak.uni-bielefeld.de</a>> wrote:<br>
> * How will services / RPC be implemented with DDS? Is there already an<br>
> accepted standard protocol for doing RPC over DDS?<br>
<br>
</div>My understanding is: (i) the current DDS spec doesn't include what we<br>
call services; (ii) there's an extension for services that is<br>
currently under consideration and may make its way into a future<br>
revision of the spec; and (iii) some current implementations have<br>
vendor-specific extensions for services.<br></blockquote><div><br></div><div>I know that many people feel otherwise, but in my personal opinion, services are a bad idea anyway, and what we really want is something more like (though not necessarily exactly the same) what actionlib offers. That is, something which *explicitly* acknowledges that there are always packets/messages underneath, that there is asynchronicity, and that there may be impossibility to act *in the protocol*.<br>
<br></div><div></div><div>Just saying ;-)<br></div><br></div>cheers<br clear="all"></div><div class="gmail_extra"><br>-- <br><div dir="ltr">Ingo Lütkebohle, Dr.-Ing.<br>Machine Learning and Robotics Lab, IPVS, Universität Stuttgart<br>
<a href="http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle" target="_blank">http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle</a><br><a href="tel:%2B49-711-685-88350" value="+4971168588350" target="_blank">+49-711-685-88350</a><br>
<br>PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B</div>
</div></div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>ros-users mailing list</span><br><span><a href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a></span><br>
<span><a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a></span><br></div></blockquote></div></div></div><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div>