On Mon, Mar 19, 2012 at 7:11 PM, Jukka Zitting <jukka.zitt...@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 api. > > 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 intentionally 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. cheers stefan > > 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
