jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mat Lowery <mlow...@pentaho.com>
Subject Re: Practical limitations on the number of workspaces
Date Thu, 17 Dec 2009 01:01:30 GMT
Here's a page you might want to consult:


On Wed, 2009-12-16 at 16:00 -0800, Alan Chaney wrote:

> Hi
> I'm a complete newbie to using Jackrabbit. I'm designing a system in 
> which I intend to manage a very large number of multimedia assets using 
> JR workspaces as libraries. The library would have different node types 
> depending upon the type of asset, which can be of various types, from a 
> few lines of text to multi-megabyte binary files.
> Sorry if the following appears a dumb question, but I haven't yet really 
> got very much experience with the practical side of JR. I've read both 
> JSR 170 and JSR 283 but reading the specs is no substitute for hands on 
> practical experience. Ideally I'd experiment, but sadly I'm under a bit 
> of time pressure and so I'm  hoping that people on this would be able to 
> give me some advice.
> In our application users have their own "workbench" which is like a 
> playground in which they can experiment with assets. It seems to me that:
> 1. I could implement the domain objects for the workbench and use an ORM 
> to persist the relationships between this domain objects. These would 
> contain references to nodes in the library which would be JR and this 
> would provide the information required to deliver the data to the user.
> or
> 2. I could implement the "workbench" domain structure as jackrabbit 
> nodes and have one workspace for each user. This may be 1000s of users 
> (eventually). What are the practical limits on the number of jackrabbit 
> workspaces - is it possible to have 100s or 1000s? The individual users 
> workspaces would have references to some of the library items but the 
> library would not have any references to the users items.
> Regards
> Alan Chaney

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message