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