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 Tue, 20 Mar 2012 11:30:00 GMT
On 2012-03-20 10:57, Stefan Guggisberg wrote:
> 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
> api.

So we have a wrapper, providing a slighty stronger typed API, have that 
produce JSON/JSOP messages, and feed those into an implementation that 
parses them again?

Can you elaborate on how exactly this is better then having it the other 
way around?

/me confused

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

IMHO it only looks low-level, because it hides all the complexity in the 
string format for commit(), which, btw, is not defined anywhere in the 
API yet.

> 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 think the "unnecessary serialization/parsing" argument is a strong 
one, and not only a matter of personal preferences.

That being said; I'm actually *very* interested in an efficient 
protocol. But that shouldn't make the implementation of JCR on top of 
unnecessary complex.

If the data model we have is essentially a JavaScript object tree, what 
would be wrong with exchanging Java maps (containing strings, numbers, 
and nested maps)?

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

I'm not sure how you come to that conclusion.

Third party implementations can implement the API, and re-use a protocol 
layer on top of it.

Or they could implement the protocol directly, in which case the caller 
would need to access them though the protocol, even when on the same 

Best regards, Julian

View raw message