jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: MicroKernel API vs. protocol
Date Mon, 19 Mar 2012 20:31:47 GMT
On 2012-03-19 19:11, Jukka Zitting 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

Indeed.

> amount of information that needs to pass across the interface.

...which I believe is something worth to keep even in a Java API.

> 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.

Right. Serializing objects to strings just for the purpose of parsing 
them again makes little sense to me. It's something that you indeed need 
to do on the wire, and yes, we should define this as well, but it 
doesn't need to be the only way to do it.

There's also a concern that isn't directly about strings vs objects but 
about "flat or not". Forcing getNodes to return things as a hierarchy, 
when it also could be a list of objects, decorated with a path, will 
make it harder than it needs to be to process efficiently.

> 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.

+1

> 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?

I believe that in order to remote things efficiently, we still need to 
be able to optimize the number of requests. This means asking for a set 
of NodeStates, for a hierarchy, and also filtering the result set (or 
selecting specific parts of the hierarchy).

I probably sound like a broken record but there's a reason why WebDAV's 
PROPFIND/multistatus looks the way it does.

Best regards, Julian

Mime
View raw message