2017-11-08 16:24 GMT+01:00 Ivan Kelly <[email protected]>: > >> 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. >
Or simply we should support a WebSocket endpoint for writers, once the websocket connection is closed the ledger gets closed and maybe for "tailing" readers > > 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 >
