jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: MicroKernel API vs. protocol
Date Tue, 20 Mar 2012 20:40:44 GMT

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

It would actually make sense the other way around: to have a strongly 
typed API with protocol bindings on top where needed.

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

What is that intention? Is it still valid? I see quite a bit of risk 
introducing a legacy here before we even start.

> 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 don't think so. By using strings instead of Java data types:
- we lose strong typing which will cause bugs which otherwise would be 
caught by the compiler
- we add complexity by the need to serialise/deserialise
- we mix the concerns of application logic and serialisation/deserialisation
- we cause headaches further down the line in maintaining the code latter on
- we make the code harder to read which raises the bar for new developers
- we make refactoring harder and using data type based refactoring tools 
(like modern IDEs provide) impossible
- we add performance penalties caused by unnecessary 
serialisation/deserialisation
- we loose the ability of the compiler to optimize the code

Going down that route we are giving up on very well established 
engineering practices and we should have really good reasons in doing so.

Michael

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


Mime
View raw message