atom feed13 messages in org.apache.jackrabbit.devJackrabbit 3: repository requirements
FromSent OnAttachments
Jukka ZittingFeb 9, 2010 7:55 am 
Andrey AdamovichFeb 9, 2010 8:19 am 
Jukka ZittingFeb 9, 2010 8:31 am 
Guo DuFeb 9, 2010 2:04 pm 
Torgeir VeimoFeb 9, 2010 2:08 pm 
KÖLL ClausFeb 10, 2010 4:42 am 
Alexander KlimetschekFeb 10, 2010 6:16 am 
Felix MeschbergerFeb 10, 2010 6:34 am 
ulf schneiderFeb 10, 2010 11:52 pm 
Ian BostonFeb 17, 2010 3:30 am 
Bart van der SchansFeb 17, 2010 2:17 pm 
Ilya SkorikFeb 17, 2010 8:28 pm 
Ilya SkorikFeb 17, 2010 8:39 pm 
Subject:Jackrabbit 3: repository requirements
From:Jukka Zitting (
Date:Feb 9, 2010 7:55:19 am


Now that Jackrabbit 2.0 is out and the major JCR 2.0 feature work is done, it's time to start looking ahead at Jackrabbit 3. We've talked about this a bit already at Day and I'll be posting a summary of our ideas for further discussion, but before that I'd like to frame the discussion by getting a better picture of the range of requirements we'll be having for Jackrabbit 3.

So, please let us know what you expect your repositories to look like within the next five or so years. I'm especially interested in answers to the following questions:

Scalability: * How much content (number of documents/nodes, raw amount data in GB/TB/PB) do you have in the repository? * How many (concurrent) users (readers/editors/administrators) does your repository have? * Do you need Internet-scale (millions of users or exabytes of content) features?

Deployment: * Do you run the repository on a single server, on a cluster or in the cloud? * How many and how powerful servers do you use for the repository?

Content model: * Do you need support for flat content hierarchies (>>10k sibling nodes)? * Do you need support for same-name siblings? * If you use versioning, how actively (commit on all saves / commit only at major milestones) and for what purpose (revision history, backup, etc.) do you use it? * How granular (hierarchies of small properties vs. big binary blobs) is your content? * How much of your content access is based on search / tree traversal / following references? * How much you rely on the repository to enforce your content model (node type constraints, etc.)? * How often you modify your content model (and/or related node types)?

Features: * Do you need full ACID semantics? Is an "eventually consistent" system good enough for you? * Do you need more powerful search features than what we now have? * How important is observation to your application? Do you need trigger-like capability that can modify or reject a save() operation?

Feel free to answer either based on your current usage patterns or to predict your needs for the next few years. The further ahead in the future you can reasonably predict, the better.

Note that I intentionally restricted this set of questions to core repository features, I'll do a poll on favorite new features later on.