Cool.  Some more things to throw out there:

 * One thing that let me to Redis was I was also experimenting with TTL.
 This seemed to be an interesting concept (e.g., expiring an 'initialized'
parameter/calibration/pose).  Wasn't sure if it would be useful, but it was
at least interesting.
 * Another thing that led me to Redis was its support for Sets.  These Sets
are very powerful; e.g. Instagram uses Redis Sets to represent the photos
you see in your stream.

And finally:

 * Right now you're motivated to extract the Parameter Server from the
Master. I agree that it's useful to decouple them.  But, to warp things a
bit, a Redis-backed, TTL supporting Key/Value store would make a great
backend for a master.  i.e., the Master is little more than a special set
of Parameter APIs using Sets, TTLs, and PubSub.

cheers,
Ken



On Wed, Apr 17, 2013 at 7:22 AM, Jack O'Quin <jack.oquin@gmail.com> wrote:

> On Wed, Apr 17, 2013 at 8:06 AM, Gonzalo Abella <abellagonzalo@gmail.com>
> wrote:
> > Thank you very much for your answers. They are all pretty helpful. A
> > brief summarize:
>
> > - But (a possibility), rely on a simple key-value DB as Redis to
> > minimize development/maintenance.
>
> +1 to redis
>
> > - Priorities to initialize parameters: (0) default values, (1) launch
> > files, (2) parameter server, (3) command line. +number -> +priority
>
> Not sure why the server needs to worry about this. Parameters get set
> whenever someone sets them. Not your responsibility, its under user
> control.
>
> > The params lifecycle is a tricky problem. I think the best solution
> > would be a combination of both live/die with paramserver and live/die
> > with parent. It is reasonable to have global parameters which do not
> > depend on any node (or depend on the ROS Master). But other
> > parameters, such as private params, are meaningless and they should be
> > removed from the param server.
>
> Beware: in the existing implementation, parameters live and die with
> the parameter server (currently roscore). That is often useful.
>
>  * I often find myself starting roscore first just so I don't have to
> reload parameters every time I test some node.
>
>  * Sometimes parameters may be adjusted during node execution. If they
> are destroyed when the node terminates, we lose the opportunity to
> save them somewhere for the next session.
>
>  * For general compatibility, interface issues like this should not be
> changed without a compelling reason.
> --
>  joq
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>