On 9 September 2011 02:34, I Heart Robotics <iheartrobotics@gmail.com>wrote:

> 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?

Regards,
Daniel Stonier.


> --
> I Heart Robotics
> http://www.iheartrobotics.com
> <3
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>