1. http?http is going to be out of date soon.. I would suggest http2 based grpc: http://www.grpc.io/ It also facilitates other client language choices. 2. ttl?If you want to create an ephemeral node, TTL isn't a good design. The notion of TTL comes from the lease in Chubby. It's all about motivations. IIUC, ZooKeeper was built for:- configuration management (metadata store)- leader election Other than these two, etcd provides one more: distributed version management. This is related to Kubernetes design. 3. redesign?Any plan to start ZK-4? A summer project would be enough to start :) - Hongchao Deng
> Date: Wed, 8 Apr 2015 15:09:25 -0400 > Subject: design thoughts: node TTLs > From: [email protected] > To: [email protected] > > 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
