I agree that they have to write clients that do work, but there is clearly a desire and willingness out there to do that work in exchange for a more "obvious" way of interacting. So supporting it should be something that we consider if the users of such systems want the option.
On Sat, Apr 11, 2015 at 12:07 PM, Jordan Zimmerman < [email protected]> wrote: > REST has issues for end users. They will still have to write clients and > do a lot of extra work. REST support is good in most languages but having > native support is superior. That’s why I choose Thrift for the CuratorRPC > Proxy. > > -Jordan > > > On April 10, 2015 at 9:32:47 PM, Michi Mutsuzaki ([email protected]) > wrote: > > Yeah it's quite painful to manage another set of processes just for > proxying requests. I'd definitely use this if I can run it embedded in > the ZooKeeper process. I'm very excited about the idea of being able > to use curl to look at what's in ZooKeeper :) > > On Fri, Apr 10, 2015 at 6:03 PM, Patrick Hunt <[email protected]> wrote: > > 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 > >> >> > > >> >> > > >> >> > >> > > >> > > >> >
