jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Notes from the Oakathon
Date Wed, 04 Jul 2012 15:35:44 GMT
On Wed, Jul 4, 2012 at 2:37 PM, Michael Dürig <mduerig@apache.org> wrote:
> 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

i don't remember any discussions that sling should be using
an alternative interface to access the repository. IMO
sling should only use the jcr api.


> 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

View raw message