Hi,
Right after the Berlin Hackathon Oak saw another quite busy week with
another Hackathon in Basel:
- A Microkernel performance test suite was contributed by Tudor Rogoz
through OAK-335. Thanks Tudor! This should eventually be a great help
for identifying scalability and performance bottlenecks in the various
Microkernel implementations and its a great fit to the Mongo based
Microkernel implementations that was contributed only recently.
- There was some discussion whether the commit hook should rather be
located in RootImpl instead of KernelNodeState/Branch. There is also the
question whether we want/need a testAndSet operation for the
Microkernel. See here for some background:
http://wiki.apache.org/jackrabbit/Transactional%20model%20of%20the%20Microkernel%20based%20Jackrabbit%20prototype
- Since OAK-325 we have support for node types in query. Implementation
wise, a better approach might be to have that functionality in the core
query engine to avoid duplication. Even better could be to support
pluggable "query transformers" that could modify the abstract syntax
tree based on custom rules (like node type inheritance) before it is
passed on to the actual index implementations.
- The recent work on initial repository setup (OAK-41) still raises some
questions: initialisation is in the wrong layer and mixes oak-core with
JCR only aspects. Also how could we perform initial setup without
security checks? Some rough ideas were discussed, so expect to hear more
about this soon.
- There was a discussion on the state of the Oak API. The Java API is in
a reasonably stable state with only smaller details and some missing
features still to be added. Open questions resolve around how to handle
workspaces, versioning, some access control bits, etc. These might be
best decided once someone has had a chance to take a deeper look on how
the implementation should look like.
The HTTP binding for non-Java clients is still largely undefined and
there's only a very early draft implementation. There are two aspects to
the HTTP binding: remoting of the Java API vs. direct access from
non-Java clients. Regardless of this, the interface for non-Java clients
should be simple yet functionally complete and it should be possible to
do complex stuff without a complex client-side library for coordinating
the interaction. We might want to leverage existing standards/work where
it makes sense (WebDAV, JSON-LD, etc).
- Support for orderable child nodes should move from oak-jcr to
oak-core: for access control reasons the current childOrder property
needs to be hidden below the Oak API (otherwise information about
otherwise unaccessible nodes might be leaked). See the recent discussion
on OKA-169.
- A lot of consolidation happened around the management of query
indexes. See OAK-365, OAK-368 and OAK-362 for details.
- OAK-366 makes the MongoDB backed Microkernel implementation OSGI ready.
- With OAK-350 there is an effort to unify PropertyState and CoreValue
in order to reduce the number of runtime instances and to reduce the
complexity of the API for the major use cases.
- Finally, there was quite a lot going on in the security area wrt.
access control, authentication support, principal management and so.
Angela, since you were mainly concerned with this, do you mind to give a
quick update on what's new here?
so long,
Michael
