jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Jackrabbit 3: repository requirements
Date Tue, 09 Feb 2010 15:55:19 GMT

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:

* 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?

* 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)?

* 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.


Jukka Zitting

View raw message