Hi Sean, Thanks for sharing the Info.
I am also thinking of implementing each user's content store as a Workspace. Each workspace would have two top-level nodes hanging from its root: Private and Public. Then each of those two nodes would contain many, many content Items.
Given your requirements that you would like users to query each others "information stores", I wanted to ask if a user can query only the "Content" of any single other users at a time or would you like to query all the content with a single query? (Obviously respecting access control) If yes, I would recommend to store all the "home directories" in a single workspace, since this would allow to query with a single query.
Is there anything so far that wouldn't be well served by building on top of Jackrabbit?
Personally, I think this is a very well suited set of requirements for a JCR-based application.
Am I right in assuming (given my ideas above) that cross-workspace queries are perfectly possible, and that all that is required is a separate, logged-in Session to each one?
Queries operate on a single workspace. In your scenario there is not really a drawback of using a single workspace, or in other words not really a need to incurr the overhead of a "per user workspace". Multiple workspaces become a requirement if you want to leverage the cross-workspace methods such as merge(), update(), clone() etc...
Can you envisage any issues (performance or otherwise) with my pitifully meagre outline? Any sage words of advice on how to best start architecting my repository?
I think using JCR for an application like yours is great. I would also recommend to hack away and inform this list of possible perfomance bottlenecks that you run into. The good news about using a standard like JCR is that you are not bound to a single implementation, meaning that if you find out, a couple of years down the road that Jackrabbit doesn't cover your performance needs anymore you can always switch to commercial or other opensource alternatives. regards, david
