<div dir="ltr">Hi,<br><br>2014-02-18 9:42 GMT+01:00 Ingo Lütkebohle <<a href="mailto:iluetkeb@gmail.com">iluetkeb@gmail.com</a>>:<br>> I know that many people feel otherwise, but in my personal opinion, services are a bad idea anyway, <div>
> and what we really want is something more like (though not necessarily exactly the same) what actionlib </div><div>> offers. That is, something which *explicitly* acknowledges that there are always packets/messages </div>
<div>> underneath, that there is asynchronicity, and that there may be impossibility to act *in the protocol*.<br><br>Just to make sure there is no misunderstanding: I did not want to advocate the use of services (actually we are fully in the event-driven camp). Instead, I wanted to point out that this is an additional issue that needs consideration when switching ROS transport over to DDS as I suppose that there exist a number of components that rely on the service API.<br>
<br>Still, users will most likely expect (a)synchronous remote procedure call / query / task patterns with or without feedback that are well supported. Conceptually, the realization of these patterns in event-based architectures are well documented in the literature, cf. [1] for an intro. From my perspective, the question is rather how to realize these in a usable, efficient and possibly standardized way without complicating the user-level API.</div>
<div><br></div><div>In any case, it would be good if future implementations of these patterns support recording through tools such as rosbag, cf. also [2], which should be easily possible if it is realized in an event-based manner. </div>
<div><br></div><div>Best, </div><div><br></div><div>Sebastian<br><br>[1] Faison, Ted ; Hassel, J. (ed.): Event-Based Programming: Taking Events to the Limit. Berkeley, CA. Chapter 9: Event-based Interactions. Apress, 2006<br>
[2] <a href="https://github.com/ros/ros_comm/issues/250">https://github.com/ros/ros_comm/issues/250</a></div></div>