Hi,
Last week some of us met for another small Oakathon in Basel. Below is a
list of topics that where touched and worked on and the related Jira
issues. Any additional input is appreciated.
- Observation (OAK-144):
* Observation events don't report every single event but rather a
consolidated view at a given time (basically a a diff). Rational:
performance on heavy write systems, (order of) individual events not
clear/different for different cluster nodes in clustered setup.
* Implement user data support on a best effort basis. In a clustered
setup this can't be supported. See also
http://markmail.org/message/osxupy3twc3pyild
* oak-core should provide lightweight mechanism for clients to
discover changes. oak-jcr can use this to implement JCR observation on
top and trade off performance implications as needed.
- Internal value handling
* To reduce GC overhead we should try to keep the number of small
objects down
* Possibly merge CoreValue into PropertyState
* Use flyweight instances for common values/properties
- HTTP bindings (OAK-103, OAK-104)
* Provide extension points for Sling to hook into. (See also the
discussion on @oak-dev: http://markmail.org/message/tzpbxf5zduybezya.)
- Full text index (OAK-154)
* Added an initial Lucene index stored under /jcr:system/oak:lucene
in the repository (final location(s) TBD)
* Index updates in a CommitEditor hook, so the index is always up to
date with latest content changes
+ TODO: How to postpone time-consuming indexing operations like
full text extraction
+ TODO: How to merge conflicts in the search index?
* Basic QueryIndexProvider allows the existing query engine to
leverage the Lucene index
+ TODO: Integrate with the rest of the build
- Merge/rebase logic handling (OAK-157)
* The Lucene index work encountered some issues with the way we
handle the merge/rebase operations
* Need to look deeper into that over the next few weeks
Michael
