I've lost the thread now. Are we talking about inside of the ZK servers themselves, or as a proxy in front of them?
On Mon, Apr 13, 2015 at 1:35 PM, Jordan Zimmerman < [email protected]> wrote: > I agree that get/set kinds of things is useful - especially for OPs > groups. What if ZK had some sort of pluggable server support? Ops folks > could plug in a simple REST server, others could plug in a Thrift server, > etc. > > > > On April 13, 2015 at 12:31:51 PM, Patrick Hunt ([email protected]) wrote: > > I think it depends on the use case. I've had a number of folks asking for > the REST support, in those cases I think they are mainly interested in > active participation (get/set rather than watches/ephemerals). > > The SPEC page has all the details on what the REST proxy currently > supports. > > Patrick > > On Mon, Apr 13, 2015 at 8:35 AM, Jordan Zimmerman < > [email protected]> wrote: > > > 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 ([email protected]) 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 <[email protected]> > > 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 < > > > [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 > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > >> > > > > > >> > > > > > >> > > > > > > > > > >
