> 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

Reply via email to