Yes, pluggable is what I had in mind. My thought was that now that jetty is embedded it shouldn't be too hard to allow the REST to be registered dynamically via config.
Patrick On Mon, Apr 13, 2015 at 10:35 AM, 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 > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > >> > > > > > >> > > > > > >> > > > > > > > > > >
