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.
That sounds like a good place to start. We have Korean family week next week (much like a western christmas) - I'll push some code onto a public server once that's done and arrange a review. Do you have any objections to it being on github?
Daniel Stonier.