You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 15, 2024. It is now read-only.
Any multi-language support on the horizon? I see some smatterings of Python code, but it doesn't appear to be a full-featured client.
I have been researching BookKeeper as a potential solution for a system written in Go. However, the current API appears to be Java-only, even though the Bookie protocol (which is apparently undocumented?) is Protobuf.
I was puzzled by the fact that there is no documented wire protocol for the main server, and indeed, looking at the Java client, it looks like it is in fact a "fat" client that talks directly to both ZooKeeper and the Bookie backends.
So it appears that in order to access BookKeeper from a non-JVM language, you have to port the entire fat client.
A lot of projects in the Hadoop/Java world — Flink, Flume and Accumulo come to mind — take this Java-centric approach rather than an API-first approach. This was also also the situation Kafka was in when it launched, though the situation is much better these days. For someone outside Java land, it's a little disappointing to see relatively new projects do exactly the same thing all over again.
Are there plans to extricate all of this tightly coupled logic into a server that can offer a language-agnostic API using gRPC/Protobuf or similar?
The text was updated successfully, but these errors were encountered:
Original Issue: apache#2167
FEATURE REQUEST
Any multi-language support on the horizon? I see some smatterings of Python code, but it doesn't appear to be a full-featured client.
I have been researching BookKeeper as a potential solution for a system written in Go. However, the current API appears to be Java-only, even though the Bookie protocol (which is apparently undocumented?) is Protobuf.
I was puzzled by the fact that there is no documented wire protocol for the main server, and indeed, looking at the Java client, it looks like it is in fact a "fat" client that talks directly to both ZooKeeper and the Bookie backends.
So it appears that in order to access BookKeeper from a non-JVM language, you have to port the entire fat client.
A lot of projects in the Hadoop/Java world — Flink, Flume and Accumulo come to mind — take this Java-centric approach rather than an API-first approach. This was also also the situation Kafka was in when it launched, though the situation is much better these days. For someone outside Java land, it's a little disappointing to see relatively new projects do exactly the same thing all over again.
Are there plans to extricate all of this tightly coupled logic into a server that can offer a language-agnostic API using gRPC/Protobuf or similar?
The text was updated successfully, but these errors were encountered: