jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject MicroKernel API vs. protocol
Date Mon, 19 Mar 2012 18:11:59 GMT
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.

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.

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)

WDYT?

BR,

Jukka Zitting

Mime
View raw message