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
