[
https://issues.apache.org/jira/browse/BOOKKEEPER-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645738#comment-14645738
]
Ivan Kelly commented on BOOKKEEPER-860:
---------------------------------------
{quote}could you be more specific about what are the mistakes in current ledger
handle api? are those coding style mistakes or semantic mistakes?{quote}
It's more stuff that I would do differently now having had experience actually
using the api to build stuff. What follows is a list of things I'd do different
now.
- requiring a passwd and digest type when creating a ledger; It's not real
security, and just means you need to define a constant for passwd. There should
be sensible defaults.
- having more than 1 digest type
- over emphasis on striping (ensemble > write quorum). It's much better to have
write quorum equal to ensemble in most cases, and ack quorum one smaller.
- many different callback types. One using generics would mean less to remember
when implementing.
- using callbacks at all. ListenableFuture or rx Observables would make more
concise code at this stage.
- context objects for callbacks.
- exposure of netty socket channel factory in constructor.
- use of Enumeration for readEntries
- having reading and writing on the same handle. Users generally don't want to
be both at the same time.
- using byte[] over ByteBuffer
- reads are non-streaming. You have to ask for N entries. Most people go for
0-LAC, because it requires the least logic. Will blow up your memory if the
ledger is large.
- in general, ledger handle is far too primative to be useful. For creating a
log for a resource you need to implement a lot of complex code, especially if
you want it to be non-blocking.
For the last one, I had been working on an higher level api, and had actually
mostly implemented [1], but then I left yahoo, so I dropped it, as I no longer
had a prod usecase. It really should be driven by someone with a prod usecase.
[1] https://github.com/ivankelly/bookkeeper/tree/public-ledgerset, see
ledgerset submodule.
> Enhance client API
> ------------------
>
> Key: BOOKKEEPER-860
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-860
> Project: Bookkeeper
> Issue Type: Improvement
> Components: bookkeeper-client
> Affects Versions: 4.3.1
> Reporter: Venkateswararao Jujjuri
> Assignee: Venkateswararao Jujjuri
> Labels: newbie
> Fix For: 4.4.0
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Today's BK client API generates entryId and LedgerHandle for the caller.
> While this is very convenient and makes the life of caller very simple and
> easy,
> this model may not be very suitable where application would like to have
> better control.
> In order to facilitate applications/users of BK aspiring to have more control
> following enhancements are proposed for BK client API:
>
> - API enhancement to accept entryID:
> Enhance BK client API to pass entryId as an input and the caller must
> guarantee the following:
> * entryIds are never duplicated
> * entryIds are sequential starting from 0.
> * entryIds have no holes.
> - API enhancement to accept LedgerHandle
> Applications are allowed to pass-in ledgerId provided:
> * ledgerId is unique within the cluster.
> * Or even better, if using GUID (128 bit) virtually guarantees universal
> uniqueness.
> * Need to bypass current ledgerId generation logic.
> - Allow multiple entities (threads/processes) write to the ledger as long as
> there is only one writer at the given instance of time.
> - Currently ledgerHandle interface accepts byteArray as input, but sockets
> use byteBuffer. We will add additional functions to the new classes to
> accept both byteBuffers and byteArrays.
> - Sijie suggested to create a new classes that extents existing classes to
> accept LedgerId and entryId as inputs.This avoids any confusion with existing
> interfaces, and makes it explicit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
