On Fri, 2011-09-09 at 02:09 +0900, Daniel Stonier wrote: 
> I got started from that one - thanks for the push in the right
> direction. I was going to contact you about it, but here is as good a
> chance as any :)
> 
> 
> I ended up pushing a little further and in some different directions
> though:
> 
> 
>       * Permit any ros program to publish services of any type, not
>         just the _ros-master._tcp. 
>       * In the same vein, listening for any service type. 

I think of services offered by nodes as being subservices of ROS Master,
but if publishing services is optional I'm not opposed. However, I think
publishing every service by default is unnecessary.

I think someone needs to officially register the ROS Master service or
whatever ever primary service we decide on.

>       * Multiple publisher/listener support 
>       * Runtime addition of publishers/listeners (sometimes needed to
>         find free ports, then configure - there are other use cases
>         too).  
> 
> 
> I dropped the python implementation as it couldn't do runtime. The c++
> library had just implemented some threaded poll locking, and that
> ended up working well for runtime additions after the polling loop was
> spun up. In the end, what it resulted in was a package that had:
> 
> 
>       * A pure c++ lib that could be used by any program directly
>         (much simpler c++ api than the avahi api). 
>       * A ros node with pub/sub req/resp api for adding
>         services/listeners, listing published and discovered services
>         and publishers for new/lost services. 
>       * The node can also do static configuration from the param
>         server. 
> In most cases I'll just run the node alongside the rest of the ros
> system. If I want the ros master published, I can configure that in
> the yaml, or spin off a small python script to do the job. It can then
> also be used by any other package for any other service.

This seems reasonable. There was no particular reason it was originally
in Python.


> The android jmdns implementation is a bit different, we just kept that
> to a library api as I can't envisage (for the near future) a complex
> system of nodes running on 'droids.

This makes sense for now.

> I don't think we'll have any issue moving our zeroconf code out to a
> public server - shall we get together and polish off a zeroconf stack?

We should probably do an API Review for it since I know Victor over at
Pal Robotics will probably have some input. 
-- 
I Heart Robotics
http://www.iheartrobotics.com
<3