Hi Jukka, Interesting to see how we can get Jackrabbit ready for the next decade ;-)
Here is my feedback for the survey. > Scalability: > * How much content (number of documents/nodes, raw amount data in > GB/TB/PB) do you have in the repository? In the order of tens of millions of nodes and tens of GB of data. > * How many (concurrent) users (readers/editors/administrators) does > your repository have? readers: tens of thousands, concurrent editors: hundreds, admins: just a few. > * Do you need Internet-scale (millions of users or exabytes of > content) features? We will probably not go over serveral TBs of data and hundred of thousands of users in the next few years. > > Deployment: > * Do you run the repository on a single server, on a cluster or in the cloud? Usually custom clusters, but we're looking at (private) cloud options. > * How many and how powerful servers do you use for the repository? Between 2 to 16. > > Content model: > * Do you need support for flat content hierarchies (>>10k sibling nodes)? Yes! > * Do you need support for same-name siblings? Not really. > * 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? We use versioning actively on workflow steps like publish, take offline, save document, etc. > * How granular (hierarchies of small properties vs. big binary blobs) > is your content? Lot's of small properties, but also blobs up to 100MB, but we would like to store larger blobs for things like movies. > * How much of your content access is based on search / tree traversal > / following references? We use searches and tree traversal a lot, but we try to avoid (hard) references. > * How much you rely on the repository to enforce your content model > (node type constraints, etc.)? We use strictly enforced content models. > * How often you modify your content model (and/or related node types)? Often, but not as often as we would like, because changing nodetype definitions is quite a difficult and heavy operation right now. > Features: > * Do you need full ACID semantics? Is an "eventually consistent" > system good enough for you? "eventually consistent" would be good enough in most cases. > * Do you need more powerful search features than what we now have? Always nice to have, but I don't have any specific features in mind. ;-) > * How important is observation to your application? Do you need > trigger-like capability that can modify or reject a save() operation? We mostly need some async (persistent) events for which we use observations right now. Triggers that can "veto" operations would be a nice addition. Regards, Bart
