If I interpreted this sentence and the spirit of that section properly, the
service client does not have to be a
ROS node, and any code which could:

1) negotiate the XMLRPC handshaking (which seem to conform to some
standard), 
2) generate the proper connection header, and 
3) send and decode serialized messages (over sockets and again apparently
generated in "a" standard manner)
ought to be able to communicate with a ROS based service provider.

This should be an avenue available to code which doesn't call rospy or ROS
native code.
I'm interested in services which can communicate with ROS services but do
not require a ROS install, or at least are dependent on a modest, platform
independent segment of ROS code.

Did I over simplify what I read? 
-- 
View this message in context: http://ros-users.122217.n3.nabble.com/examples-of-non-ROS-service-clients-tp1636253p1642837.html
Sent from the ROS-Users mailing list archive at Nabble.com.