You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2012/06/28 13:43:15 UTC

Updated Oak roadmap

Hi,

We missed pushing the 0.3 release out a month ago, but let's fix that
by cutting the release instead of 0.4 now at the turn of the month.

And since we're reaching the end of the initial roadmap [1] we drafted
in February, I think it's a good idea to now review where we are and
outline some targets for the next few months.

First a quick review of the originally outlined release milestones:

* 0.1 - March 2012 - ALL DONE
* 0.2 - April 2012 - PARTIALLY DONE, STILL MISSING:
  * Basic in-cloud persistence
  * Runnable jar with "join cluster" functionality
  * Integration tests to verify the above
* 0.3 (wasn't released) - May 2012 - ALL DONE
* 0.4 (to be released as 0.3) - June 2012 - PARTIALLY DONE, STILL MISSING:
  * Bindings for jQuery
  * Basic support for access control based on the extension model
  * Basic support for node types based on the extension model
  * Basic support for observation based on the extension model
  * Basic support for locking (if needed/wanted)
  * Integration tests to verify the above
  * Performance benchmark against selected other NoSQL databases
  * Performance tests for clustered deployments
  * Basic scalability tests for simple read and write scenarios

We're making good progress on things like (basic versions of)
observation and locking, so I guess we'll still be able to know a few
of the above items by the end of the month before cutting the next
release. However, a few items like clustered deployments or
nice-to-have features like jQuery bindings need to be postponed to
future releases.

Below are a few initial ideas of what we should focus on going forward.

* July 2012 (0.4)
  - Increased coverage of core JCR functionality (node types,
observation, security, etc.)
  - Finish the JAAS authentication work
  - Full text search based on Lucene
  - Integration with Apache Sling
* August 2012 (0.5)
  - ACL-based access control
  - XML and other batch import features
  - Versioning, workspaces, etc.
* September 2012 (0.6)
  - Scalability and performance review
  - Pass the TCK test of all the JCR features we want to support (i.e.
JCR compliance)

These are just from the top of my head for now as a discussion
starter. Feel free to disagree with the timing and suggest changes.
The main purpose here is to get a shared understanding of what are the
key areas to work on in the next few months instead of setting hard
deadlines.

[1] http://markmail.org/thread/7dhxklytr2xaoe24

BR,

Jukka Zitting

Re: Updated Oak roadmap

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Thu, Jun 28, 2012 at 3:38 PM, Angela Schreiber <an...@adobe.com> wrote:
> IMO your schedule for security related tasks is way too
> ambitious and i don't see that happen within the timeframe you
> stated below.

Fair enough, you have a much better view of how much effort
implementing these features requires and how much time you or others
who could implement them have available in near future. I'm coming at
this more from a top-down perspective of how different parts could
ideally come together, but of course we also need to take other
constraints into account.

What do you think would be a reasonable roadmap/timescale for the
security features? If we already know that these features won't be
available until later, then we can adjust the other parts of the
roadmap accordingly (for example we already know that our performance
benchmarks won't tell the full story until we have also ACL evaluation
in place).

BR,

Jukka Zitting

Re: Updated Oak roadmap

Posted by Angela Schreiber <an...@adobe.com>.
hi jukka

IMO your schedule for security related tasks is way too
ambitious and i don't see that happen within the timeframe you
stated below.

it really makes me feel very uneasy that i try to explain this
to you for months now and my concerns are just being ignored.

kind regards
angela

On 6/28/12 1:43 PM, Jukka Zitting wrote:
> Hi,
>
> We missed pushing the 0.3 release out a month ago, but let's fix that
> by cutting the release instead of 0.4 now at the turn of the month.
>
> And since we're reaching the end of the initial roadmap [1] we drafted
> in February, I think it's a good idea to now review where we are and
> outline some targets for the next few months.
>
> First a quick review of the originally outlined release milestones:
>
> * 0.1 - March 2012 - ALL DONE
> * 0.2 - April 2012 - PARTIALLY DONE, STILL MISSING:
>    * Basic in-cloud persistence
>    * Runnable jar with "join cluster" functionality
>    * Integration tests to verify the above
> * 0.3 (wasn't released) - May 2012 - ALL DONE
> * 0.4 (to be released as 0.3) - June 2012 - PARTIALLY DONE, STILL MISSING:
>    * Bindings for jQuery
>    * Basic support for access control based on the extension model
>    * Basic support for node types based on the extension model
>    * Basic support for observation based on the extension model
>    * Basic support for locking (if needed/wanted)
>    * Integration tests to verify the above
>    * Performance benchmark against selected other NoSQL databases
>    * Performance tests for clustered deployments
>    * Basic scalability tests for simple read and write scenarios
>
> We're making good progress on things like (basic versions of)
> observation and locking, so I guess we'll still be able to know a few
> of the above items by the end of the month before cutting the next
> release. However, a few items like clustered deployments or
> nice-to-have features like jQuery bindings need to be postponed to
> future releases.
>
> Below are a few initial ideas of what we should focus on going forward.
>
> * July 2012 (0.4)
>    - Increased coverage of core JCR functionality (node types,
> observation, security, etc.)
>    - Finish the JAAS authentication work
>    - Full text search based on Lucene
>    - Integration with Apache Sling
> * August 2012 (0.5)
>    - ACL-based access control
>    - XML and other batch import features
>    - Versioning, workspaces, etc.
> * September 2012 (0.6)
>    - Scalability and performance review
>    - Pass the TCK test of all the JCR features we want to support (i.e.
> JCR compliance)
>
> These are just from the top of my head for now as a discussion
> starter. Feel free to disagree with the timing and suggest changes.
> The main purpose here is to get a shared understanding of what are the
> key areas to work on in the next few months instead of setting hard
> deadlines.
>
> [1] http://markmail.org/thread/7dhxklytr2xaoe24
>
> BR,
>
> Jukka Zitting

Re: Updated Oak roadmap

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Thu, Jun 28, 2012 at 5:00 PM, Thomas Mueller <mu...@adobe.com> wrote:
> Well, I think what is available in the Oak project should also be
> performant, so we should test for it...

Agreed. I just think that our default MK implementation should be
easily clusterable so that people can scale up a default deployment
without having to migrate all their content to another MK
implementation.

It's nice if the performance of a development or testing deployment
where you just have a single node is good, but in practice all really
performance-critical production deployments will have at least a few
cluster nodes (at least for high availability if for nothing else),
which is why I think that's where we should focus our performance
benchmarks (and why I really would have liked to see at least an
initial clustered MK hit Oak trunk already a few months ago ;-).

BR,

Jukka Zitting

Re: Updated Oak roadmap

Posted by Thomas Mueller <mu...@adobe.com>.
Hi,

>Yes, we can do such a benchmark (the oak-bench component already has
>the basics in place), though personally I don't see the single-node
>case as a particularly interesting one to benchmark. Unless we want to
>also target embedded systems, any truly performance-critical
>deployments will probably in any case be clustered.

Well, I think what is available in the Oak project should also be
performant, so we should test for it... According to the stated goals in
the pom.xml and Oak web site:

    "The goal of the Oak effort within the Apache Jackrabbit project is
    to implement a scalable and performant hierarchical content repository
    for use as the foundation of modern world-class web sites and other
    demanding content applications."

If that's not the case, then we should change the web site and the pom.xml
accordingly.

Regards,
Thomas



Re: Updated Oak roadmap

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Thu, Jun 28, 2012 at 3:17 PM, Thomas Mueller <mu...@adobe.com> wrote:
> I was thinking about the default MicroKernel implementation (without
> clustering), to verify performance is on the same order of magnitude than
> Jackrabbit 2.x and the underlying storage engine (the H2 database in our
> case).

Yes, we can do such a benchmark (the oak-bench component already has
the basics in place), though personally I don't see the single-node
case as a particularly interesting one to benchmark. Unless we want to
also target embedded systems, any truly performance-critical
deployments will probably in any case be clustered.

BR,

Jukka Zitting

Re: Updated Oak roadmap

Posted by Thomas Mueller <mu...@adobe.com>.
Hi,

I was thinking about the default MicroKernel implementation (without
clustering), to verify performance is on the same order of magnitude than
Jackrabbit 2.x and the underlying storage engine (the H2 database in our
case). See also 
http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackrab
bit%203

Regards,
Thomas


On 6/28/12 2:52 PM, "Jukka Zitting" <ju...@gmail.com> wrote:

>Hi,
>
>On Thu, Jun 28, 2012 at 1:58 PM, Thomas Mueller <mu...@adobe.com> wrote:
>> I would prefer if the "Scalability and performance review" would start
>> earlier.
>
>Me too, but for such a review won't make much sense before we have a
>clustered/distributed MicroKernel implementation in Oak. Otherwise the
>review will just conclude that whatever we do, the scalability and
>performance of Oak is limited by the capacity of the single server on
>which the MicroKernel is running.
>
>I'm not yet sure about the schedule of when and how we'll be able to
>have such a MicroKernel (it's basically the clustered deployment bit
>that we've been missing already since 0.2), which is why I didn't yet
>include it in the draft roadmap, but that's definitely something we
>should figure out within the next few months.
>
>PS. Adobe is currently working on such a MK implementation, but we've
>yet to figure out which parts of it we can/should contribute to Oak.
>
>BR,
>
>Jukka Zitting


Re: Updated Oak roadmap

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Thu, Jun 28, 2012 at 1:58 PM, Thomas Mueller <mu...@adobe.com> wrote:
> I would prefer if the "Scalability and performance review" would start
> earlier.

Me too, but for such a review won't make much sense before we have a
clustered/distributed MicroKernel implementation in Oak. Otherwise the
review will just conclude that whatever we do, the scalability and
performance of Oak is limited by the capacity of the single server on
which the MicroKernel is running.

I'm not yet sure about the schedule of when and how we'll be able to
have such a MicroKernel (it's basically the clustered deployment bit
that we've been missing already since 0.2), which is why I didn't yet
include it in the draft roadmap, but that's definitely something we
should figure out within the next few months.

PS. Adobe is currently working on such a MK implementation, but we've
yet to figure out which parts of it we can/should contribute to Oak.

BR,

Jukka Zitting

Re: Updated Oak roadmap

Posted by Thomas Mueller <mu...@adobe.com>.
Hi,

I would prefer if the "Scalability and performance review" would start
earlier.

Regards,
Thomas


On 6/28/12 1:43 PM, "Jukka Zitting" <ju...@gmail.com> wrote:

>Hi,
>
>We missed pushing the 0.3 release out a month ago, but let's fix that
>by cutting the release instead of 0.4 now at the turn of the month.
>
>And since we're reaching the end of the initial roadmap [1] we drafted
>in February, I think it's a good idea to now review where we are and
>outline some targets for the next few months.
>
>First a quick review of the originally outlined release milestones:
>
>* 0.1 - March 2012 - ALL DONE
>* 0.2 - April 2012 - PARTIALLY DONE, STILL MISSING:
>  * Basic in-cloud persistence
>  * Runnable jar with "join cluster" functionality
>  * Integration tests to verify the above
>* 0.3 (wasn't released) - May 2012 - ALL DONE
>* 0.4 (to be released as 0.3) - June 2012 - PARTIALLY DONE, STILL MISSING:
>  * Bindings for jQuery
>  * Basic support for access control based on the extension model
>  * Basic support for node types based on the extension model
>  * Basic support for observation based on the extension model
>  * Basic support for locking (if needed/wanted)
>  * Integration tests to verify the above
>  * Performance benchmark against selected other NoSQL databases
>  * Performance tests for clustered deployments
>  * Basic scalability tests for simple read and write scenarios
>
>We're making good progress on things like (basic versions of)
>observation and locking, so I guess we'll still be able to know a few
>of the above items by the end of the month before cutting the next
>release. However, a few items like clustered deployments or
>nice-to-have features like jQuery bindings need to be postponed to
>future releases.
>
>Below are a few initial ideas of what we should focus on going forward.
>
>* July 2012 (0.4)
>  - Increased coverage of core JCR functionality (node types,
>observation, security, etc.)
>  - Finish the JAAS authentication work
>  - Full text search based on Lucene
>  - Integration with Apache Sling
>* August 2012 (0.5)
>  - ACL-based access control
>  - XML and other batch import features
>  - Versioning, workspaces, etc.
>* September 2012 (0.6)
>  - Scalability and performance review
>  - Pass the TCK test of all the JCR features we want to support (i.e.
>JCR compliance)
>
>These are just from the top of my head for now as a discussion
>starter. Feel free to disagree with the timing and suggest changes.
>The main purpose here is to get a shared understanding of what are the
>key areas to work on in the next few months instead of setting hard
>deadlines.
>
>[1] http://markmail.org/thread/7dhxklytr2xaoe24
>
>BR,
>
>Jukka Zitting