A fresh look at APIs is definitely in order. So, this would be a potential ZK 4.x.
> That said, we added things like rest in the past for similar reasons and it > never really took off... Would be a shame to see the same here. ZK has had a lot more activity with recent committers. So, maybe this time will be different? If at least one other person will sign up to work on it, I'll shepherd it. -JZ > On Nov 18, 2019, at 12:22 PM, Patrick Hunt <ph...@apache.org> wrote: > > There are quite a few benefits to using grpc imo. It's come up a few times > where I've been part of the discussion - ala we make it b/w compat it would > be a good move imo. Then the question becomes what else do we fix at the > same time? e.g. make version fields 64 bit rather than 32? etc... there are > a bunch of zk4 such jiras that could be addressed at the same time (and > likely in a b/w compat way - ie zk3) > > That said, we added things like rest in the past for similar reasons and it > never really took off... Would be a shame to see the same here. > > Patrick > > On Mon, Nov 18, 2019 at 6:48 AM Jordan Zimmerman <jor...@jordanzimmerman.com> > wrote: > >>> That looks like great work. In order to address the issues, why not >> build on top of curator (https://curator.apache.org)? >> >> (Note: I'm the main author of Curator). I'd definitely try to make >> something like Curator for gRPC. I'm not sure exactly what that means at >> this point. But, my main goal is to enable non-JVM clients. We have C, >> python and few others now but they always lag with changes and are hard to >> maintain. >> >> -JZ >> >>> On Nov 18, 2019, at 9:45 AM, Jörn Franke <jornfra...@gmail.com> wrote: >>> >>> That looks like great work. In order to address the issues, why not >> build on top of curator (https://curator.apache.org)? >>> >>> I could support in case question rise with SASL, but I am not sure yet >> if I find the time to actively develop for this unfortunately >>> >>>> Am 18.11.2019 um 15:25 schrieb Jordan Zimmerman < >> jor...@jordanzimmerman.com>: >>>> >>>> Hi Folks, >>>> >>>> I've written a proof of concept implementation of a ServerCnxnFactory >> that implements gRPC. The goal is to make it possible to easily write >> ZooKeeper clients in non-JVM languages. Using the proof of concept I was >> able to write a Golang client easily. What's the interest level of >> something like this? Let's discuss if it's worth pursuing. I'd be willing >> to move this from proof of concept to production but I'll need help (1 or 2 >> co-developers). >>>> >>>> If you want to try it, I've pushed the Golang client and some >> instructions here (let me know if you have any issues - I'm a go neophyte). >> Note: "zookeeper/test.go" is the interesting file: >>>> >>>> https://github.com/Randgalt/zkgrpc < >> https://github.com/Randgalt/zkgrpc> >>>> >>>> Here's the proof of concept on the ZK server side (the interesting >> files are RpcServerCnxn.java, RpcServerCnxnFactory.java, >> RpcZooKeeperServer.java and zookeeper.proto): >>>> >>>> >> https://github.com/apache/zookeeper/compare/master...Randgalt:wip-grpc < >> https://github.com/apache/zookeeper/compare/master...Randgalt:wip-grpc> >> >>>> >>>> Issues: >>>> Writing a client, even with gRPC, will require some work. Sessions have >> to be maintained, watchers have to be maintained, etc. >>>> Currently, Jute is deeply embedded in ZooKeeper. The proof of concept >> has to emulate Jute byte buffers. Ideally, this will be abstracted so that >> only records could be used so that the gRPC connection doesn't have to keep >> marshalling/unmarshalling byte buffers >>>> I don't know enough about the gRPC client/server implementations to >> know if it will meet the needs of ZooKeeper. Anyone have experience here? >>>> I haven't completely thought through how much work it will take to >> write useful clients. As I've shown with the proof of concept simple ZK >> CRUD db operations work well. I need to spend time writing a recipe such as >> Leader Election to see how much work is required. >>>> I'm not sure how things like SASL and reconfig would work with gRPC >>>> >>>> -Jordan >> >>
