On 2012-03-20 10:57, Stefan Guggisberg wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Jukka Zitting<[email protected]> 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.
Yes.
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
machine.
Best regards, Julian
