How does the current REST code handle watches and background notifications? Are clients required to poll periodically? This is really RPC and REST is not ideal for RPC. So, as I mentioned before, I think the ZK team should consider a real RPC system like Thrift instead of REST.
-Jordan On April 11, 2015 at 1:33:03 PM, Patrick Hunt (ph...@apache.org) wrote: We pack quite a bit of functionality in our client side libraries. That's probably one of the main things you'll noticed if you try to use REST. But then if your use case is primarily configuration, or something that doesn't require sessions then the current REST support should be more than sufficient. What are the other systems doing that we are currently not doing wrt API support? I'd think that taking our current rest contrib, updating the dependencies, and deploying as part of the embedded jetty would work well with minimal effort. Patrick On Sat, Apr 11, 2015 at 9:22 AM, Camille Fournier <cami...@apache.org> wrote: > 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 < > jor...@jordanzimmerman.com> 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 (mi...@cs.stanford.edu) > > 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 <ph...@apache.org> 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 <cami...@apache.org> > > > 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 <ph...@apache.org> > 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 < > > >> > jor...@jordanzimmerman.com> 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 ( > > cami...@apache.org) > > >> >> 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 < > > >> >> jor...@jordanzimmerman.com> 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 ( > > cami...@apache.org) > > >> >> > 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 > > >> >> > > > >> >> > > > >> >> > > >> > > > >> > > > >> > > >
