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 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 > > http://www.hs-ulm.de/schlegel > http://www.zafh-servicerobotik.de/ > http://www.youtube.com/user/roboticsathsulm > http://smart-robotics.sourceforge.net/ > http://www.joser.org/ > > Am 18.02.2014 um 12:37 schrieb "Kelsey Hawkins" : > > 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" wrote: > >> On Tue, Feb 18, 2014 at 2:12 AM, Brian Gerkey wrote: >> >>> On Mon, Feb 17, 2014 at 9:06 AM, Wrede, Sebastian >>> 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 > >