<div dir="ltr">Cool.  Some more things to throw out there:<div><br></div><div style> * 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.</div>
<div style> * 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.</div><div style><br></div><div style>
And finally:</div><div style><br></div><div style> * 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.</div>
<div style><br></div><div style>cheers,</div><div style>Ken</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 17, 2013 at 7:22 AM, Jack O'Quin <span dir="ltr"><<a href="mailto:jack.oquin@gmail.com" target="_blank">jack.oquin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Apr 17, 2013 at 8:06 AM, Gonzalo Abella <<a href="mailto:abellagonzalo@gmail.com">abellagonzalo@gmail.com</a>> wrote:<br>

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