>> Writing is difficult, because the java client writer is really the core of >> BookKeeper, it deals with fencing, ensemble changes.... >> It would be simple to write a client which pushes data to bookies but all >> the LAC+fencing protocols (+ metadata management) are hard to re-implement. The http client would have a record of LAC, since any entry acked by the http endpoint, would also by definition have to be acked by the bookies.
> I don't think we need to reimplement all this details in http api. what > people probably need here, is streaming the entries to a ledger, all the > fencing are delegated to http endpoint. This means that the user should stick to the http endpoint for all adds on a single ledger, due single writer constraints. This is sensible, but it does mean a layer of coordination between endpoints to know where which ledger handles are opened. I think though, that it would make more sense to have the DL api behind an http, rather than the raw ledger API. In general I think we should be discouraging the use of the raw ledger handle apis, in favour of DL. In fact DL already has a stateless frontend with a thrift interface for writing, which is probably better than HTTP for this kind of workload anyhow. -Ivan
