[jr3] Release roadmap

[Jukka Zitting <ju...@gmail.com>]

Hi,

As a followup to the strategic plan proposal, and to help turn our
focus from abstract planning to actual deliverables, here's a quick
draft roadmap for possible releases we could/should be making still in
H1/2012. It's still necessarily incomplete (for example I excluded
query and indexing features for now as I don't yet have a good idea of
when or how they should be addressed), but I think a roadmap like this
should help us focus on the right things at the right time.

For example, IMHO agreeing on the clustering model and getting a basic
implementation in place is a fundamental decision that needs to be
done as early as possible (by April in this draft), followed soon by
merging of concurrent CRUD operations. Only after we have those in
place can we start making solid decisions about higher-level features.
This doesn't mean that we shouldn't take such features into account
when designing and implementing the clustering model, just that we
shouldn't start implementing them before the basics are in place.

This is a pretty tight schedule mostly to bring up a sense of focus
that we currently seem to be lacking. The proposed schedule should be
reachable with a few persons working full time on this, which I think
(and hope) we should be able to arrange. And it's more of a guideline
than a fixed plan, we can proceed faster on some issues if possible or
postpone others where needed. We may even decide to drop some items
entirely or introduce new items to the plan.

With that background, here's the proposed roadmap:

* 0.1 - March 2012
  * Basic JCR and HTTP interfaces (Hello, World!)
  * In-memory storage (no-need for persistence yet)
  * Runnable jar for easy deployment
  * Integration tests to verify the above

* 0.2 - April 2012
  * Basic CRUD operations over JCR and HTTP
  * Extension model for plugging in alternative storage backends
  * Basic on-disk or in-cloud persistence (no performance or stability
goals yet)
  * Clustering model that supports the above CRUD operations
  * Runnable jar with "join cluster" functionality
  * Integration tests to verify the above

* 0.3 - May 2012
  * Basic (Hello, World! -level) JavaScript-friendly HTTP API
  * Simple WebDAV layer with remote filesystem semantics
  * Automatic merging of concurrent CRUD operations
  * Extension model for plugging in features like access control, node
types, etc.
  * Basic (Hello, World! -level) implementation of one such pluggable feature
  * OSGi bundle packaging
  * Integration tests to verify the above
  * Basic performance tests for simple read and write scenarios

* 0.4 - June 2012
  * Bindings for jQuery
  * WebDAV(ex)-based remoting
  * Support for all JSON and JCR data types, including multivalued properties
  * Basic support for flat hierarchies (no performance goals yet)
  * 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)
  * OSGi/Spring/etc. pluggability of extensions
  * 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

BR,

Jukka Zitting

Re: [jr3] Release roadmap

[Jukka Zitting <ju...@gmail.com>]

Hi,

To clarify, the "basic implementation" entries I included in the
proposed roadmap are really very basic, hello world -level stuff. I'm
talking about hardcoding defaults, throwing exceptions on
unimplemented parts, etc.

The main focus for those basic implementations is to get at least some
initial approximation of the final implementation so that we can
identify potential issues in internal design and architecture as early
as possible.

For example the mentioned "basic access control" feature could well be
as simple as for example having a hardcoded ACL against a hardcoded
list of users and only supporting basic "read" and "write" controls on
properties named "acltest". Note however that such assumptions and
simplifications should *not* be reflected in the internal architecture
that guides how such access control checks are made.

That latter part is the hard task we need to focus on as early as
possible (and it certainly requires that people have enough time to
work on it). If we get that design part right (or at least close
enough), we can then schedule the more complete implementation work
more or less independently in parallel of the other parts of the
repository implementation.

We'll also need to make it clear in the roadmap that nobody will
expect such "designed, just a basic implementation for now" -features
to be usable in any production scenario.

BR,

Jukka Zitting

Re: [jr3] Release roadmap

[Felix Meschberger <fm...@adobe.com>]

Hi,

Am 23.02.2012 um 15:15 schrieb Jukka Zitting:

> This is a pretty tight schedule mostly to bring up a sense of focus
> that we currently seem to be lacking. The proposed schedule should be
> reachable with a few persons working full time on this, which I think
> (and hope) we should be able to arrange. And it's more of a guideline
> than a fixed plan, we can proceed faster on some issues if possible or
> postpone others where needed. We may even decide to drop some items
> entirely or introduce new items to the plan.

Makes sense.

As for extensibility and pluggability...

> * 0.2 - April 2012
>  * Extension model for plugging in alternative storage backends
> 
> * 0.3 - May 2012
>  * OSGi bundle packaging
> 
> * 0.4 - June 2012
>  * OSGi/Spring/etc. pluggability of extensions


IMHO extensibilty and pluggability (indexing, access control, user management have been mentioned) should be built into it right from the start and there should be a single model being used. And we should not reinvent the wheel.

Taken all together we should probably shoot for OSGi right from the start. We get the rest "for free":

  - Standalone Java Application and Web App using the Sling Launchpad
  - Testbed for applications and test cases
  - OSGi services being the extension model 

Hence I would go with OSGi from Day 0 and use the OSGi Service Registry as the mechanic for pluggability.

Regards
Felix

Re: [jr3] Release roadmap

[Angela Schreiber <an...@adobe.com>]

hi jukka

thanks for that proposal.
honestly, i think that the schedule is a far to optimistic.
but we will see...

there is one thing that is missing from my point of view:

[...]

>    * Extension model for plugging in features like access control, node
> types, etc.

we not only need a concept for authorization but also for
authentication. and related to those two parts are principal
and user management.

regards
angela