Here's the spec and readme from contrib/rest: http://svn.apache.org/viewvc/zookeeper/trunk/src/contrib/rest/SPEC.txt?view=markup http://svn.apache.org/viewvc/zookeeper/trunk/src/contrib/rest/README.txt?view=markup
The current implementation is a standalone proxy. It's not embedded in zk itself. That might be part of the reason. Patrick On Fri, Apr 10, 2015 at 4:43 PM, Camille Fournier <[email protected]> wrote: > Forgive me for not reading the code, can you share in more detail what the > existing REST proxy provides? I'm curious why people are jumping to use > etcd because of ease of use w/http access if we already have something that > works? > > On Fri, Apr 10, 2015 at 7:28 PM, Patrick Hunt <[email protected]> wrote: > > > There's the REST work in contrib. Both Andrei and I worked on that - I > did > > the basic support and Andrei added sessions and heartbeating among other > > improvements. > > > > Now that 3.5 has embedded Jetty it should be much simpler to run REST as > > part of the ZK service itself. When the original proxy work was done > Jetty > > was not yet part of ZK. > > > > Patrick > > > > On Thu, Apr 9, 2015 at 10:20 AM, Jordan Zimmerman < > > [email protected]> wrote: > > > >> 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 > >> > > >> > > >> > > > > >
