jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: MicroKernel API vs. protocol
Date Tue, 20 Mar 2012 09:57:26 GMT
On Mon, Mar 19, 2012 at 7:11 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> To help clarify the MK API I think it would be useful for us to
> distinguish between the API as such and a potential related network
> protocol used for accessing a remote MK deployment:
>    http://people.apache.org/~jukka/2012/oak-mk-protocol.png
> The MicroKernel interface as currently defined has many features of a
> network protocol. For example all argument and return values are
> serialized and the filter parameter was introduced to reduce the
> amount of information that needs to pass across the interface.
> I think we need to question this design since dealing directly with a
> "network protocol" -like API in oak-core will be quite cumbersome and
> we'll in any case need to implement a separate wrapper layer on top of
> it to hide most of the details (JSON formatting, blob streaming, etc.)
> that aren't relevant to higher level functionality.

i agree that it might make sense to implement a wrapper in the
mk api consumer side, as long as we keep the current low-level

> So I think it would make more sense to rather redefine the MicroKernel
> interface in terms of higher level constructs that abstract away the
> protocol-level details. And to put the protocol-level bits (formatting
> of diffs, etc.) into an actual protocol definition instead of a Java
> interface. That protocol can then be implemented directly by a remote
> MK implementation and consumed by a simple protocol binding for the
> Java interface.

i don't agree. IMO there's nothing wrong with the current api. it's
low-level. just because it's very straight-forward to remote IMO that
doesn't imply
that it should be spec'ed as a protocol instead of an api. it's light-weight
(very few methods) and relatively easy to implement. while i am certainly aware
that it's controversial (non-oo, string-based etc) i've not seen convincing
technical arguments so far. IMO it's rather a question of personal preferences.

i am absolutely sure that we should allow for different mk implementations.
it doesn't  make sense to have 3rd party implementations implement a
protocol instead of a single straight-forward api.

therefore, -1 for replacing the current string-based api.


> As a concrete example of what this could mean is the getNodes() method:
>    String getNodes(String path, String revision, int depth, long
> offset, int count, String filter)
> The last four arguments of this method are only relevant in terms of
> serialization. A more expressive version of the method could be:
>    NodeState getNodeState(String path, String revision)
> Or possibly even:
>    NodeState getRootNodeState(String revision)
> BR,
> Jukka Zitting

View raw message