Since Curator is now Apache and I’m no longer at Netflix, I don’t follow Netflix messages very much. Sorry about that.
-Jordan On April 9, 2015 at 12:15:02 PM, Camille Fournier ([email protected]) wrote: Thanks Jordan! I actually asked on Twitter whether Netflix had anything but didn't get a clear answer. On Thu, Apr 9, 2015 at 11:22 AM, Jordan Zimmerman < [email protected]> wrote: > FYI > > Curator now has a Thrift-based proxy that has all the ZK APIs exposed as > well as Curator’s added APIs and recipes: > > http://curator.apache.org/curator-x-rpc/index.html > > -Jordan > > On April 8, 2015 at 2:09:33 PM, Camille Fournier ([email protected]) > wrote: > > All, > > I've been doing a bit of research on etcd as part of work for an upcoming > talk, and it has gotten me thinking about what it would take to create an > http version of ZK for certain operations. For many operations you could > put an http proxy in front of ZK to translate, even implementing the > "long-poll-style" watch operation to some extent. But it would be very > hard > to do a temporary node via a proxy without a lot of proxy failover > complexity. > > As a bit of background, if you want to do an "ephemeral" node in etcd, you > basically create a key with a TTL. Unless the key is updated with a new > TTL, the key will auto-expire when the TTL is reached. Now, I have a lot > of > thoughts about this (seems like you have to implement heartbeats via http > to truly mimic ephemeral nodes which may not be as simple as all this http > sounds), but I do think that if there is appetite for easy http access for > consensus systems we should at least take the time to think about what it > would take for us to provide this. In particular, I think we'd have to > make > it possible to create a node with a TTL that is not tied to a particular > session. > > Curious to see if anyone has any thoughts on this. It seems like a bit of > a > shame that ZK, which is a good battle-tested system, is frequently being > passed-over these days because of the complexity of clients, and the fact > that it is really pretty damn hard to do a client impl in certain > languages > (Ruby is the notable one I've heard). > > Best, > C > >
