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
