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.


On Tue, Feb 18, 2014 at 6:43 AM, Christian Schlegel <schlegel@hs-ulm.de> wrote:
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)

Christian

---
Prof. Dr. Christian Schlegel
Prodekan, Studiendekan Master IS
Fakultät Informatik
Hochschule Ulm

Tel.: 0731 / 50-28242


Am 18.02.2014 um 12:37 schrieb "Kelsey Hawkins" <kphawkins@gmail.com>:

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

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.

-Kelsey

On Feb 18, 2014 3:42 AM, "Ingo Lütkebohle" <iluetkeb@gmail.com> wrote:
On Tue, Feb 18, 2014 at 2:12 AM, Brian Gerkey <gerkey@osrfoundation.org> wrote:
On Mon, Feb 17, 2014 at 9:06 AM, Wrede, Sebastian
<swrede@techfak.uni-bielefeld.de> wrote:
>  * How will services / RPC be implemented with DDS? Is there already an
> accepted standard protocol for doing RPC over DDS?

My understanding is: (i) the current DDS spec doesn't include what we
call services; (ii) there's an extension for services that is
currently under consideration and may make its way into a future
revision of the spec; and (iii) some current implementations have
vendor-specific extensions for services.

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*.

Just saying ;-)

cheers

--
Ingo Lütkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universität Stuttgart
http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle
+49-711-685-88350

PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

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

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

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