I am OK with the idea of having standard HTTP API, this will help
development of (non-Java) tools.
It is not clear to me if we are going to add an http API useful for
"managing bookies" or a new HTTP REST-like Client API to BookKeeper.
I am referring to the fact that in the proposal there are API calls to
create ledgers and to read data.
I think we should separate this two aspects and maybe it is better to
address the 'bookie management' first, which is the work that Yiming
Another point very important to me is that if we are going to introduce
management operations via http we have to take into account security, at
least TLS and some kind of authentication.
About TLS it is very simple to achieve this, every HTTP server supports TLS
About authentication the problem is not so simple, Kerberos on HTTPs is
very complex, but we need to introduce some auth mechanism.
IMHO We can require the 'http server implementation' to implement security
but out of the box we have to supply basic support at least for one
provider bundled in the distribution package.
Some API can return very large result sets like 'list ledgers', actually
the HTTP Server subsystem exchanges strings in memory, we will need to
introduce some more smart way because it would be easy to bring down the
bookie just by calling that API multiple times concurrencly (it is just an
IMHO The 'create ledger' API is not useful, due to the design of BK you
have to create a ledger and then write immediately to it, I think that such
an API should allow the client to stream the contents of the ledger in the
HTTP body at least. But I think that a more stateful http API needs to be
designed to implement a pure Http client
Maybe we should add a more narrowed motivation and add the only useful APIs
to address those issues.
For instance in my company we would like to start creating a BookKeeper Web
UI, so we need some way to talk to bookies and exchange data, but in this
case I am interested in asking to bookies their status and the effective
contents of the bookie
2017-09-13 6:09 GMT+02:00 Yiming Zang <[EMAIL PROTECTED]lid>: