jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sbarriba" <sbarr...@yahoo.co.uk>
Subject RE: Workspaces advice
Date Thu, 30 Aug 2007 06:45:50 GMT
Hi Matt,
We have a similar configuration to your scenario - multiple distinct
customers which share no content.
We create a distinct workspace for each customer as:
 * they are then guaranteed to be isolated from each other
 * we can authorise each user for one or more workspaces
 * the user interface contains various per-customer configurations e.g. List
of Values etc which we store in a standard location in each workspace
 * we can backup and restore customer data e.g. a workspace easily
 * etc

This has worked well for us thus far, apart from the pain of having database
connection settings in every workspace.xml file.
Hope this helps,
Shaun

-----Original Message-----
From: Matthew Fulford [mailto:matt.fulford@pfiks.com] 
Sent: 29 August 2007 21:29
To: users@jackrabbit.apache.org
Subject: RE: Workspaces advice

Thanks David and Stefan for your input.  May I provide some further
details, and see if your opinions change...

We have a single portal web application which houses several distinct
sites. Each site belongs to an individual client with their own set of
content items, and each site is completely isolated from all others.
Most of the portal users belong to a single site, but some (portal
administrators for example) belong to all sites.

Some node types are common across all sites, for example a basic HTML
node type. Other node types are only available to a particular site,
where that client has requested a specific content type.

With this extra information, do you still advise using a single
workspace, with top-level folder nodes for each site?

Thanks.


> -----Original Message-----
> From: uncled@day.com [mailto:uncled@day.com] On Behalf Of David
Nuescheler
> Sent: 23 August 2007 09:58
> To: users@jackrabbit.apache.org
> Subject: Re: Workspaces advice
> 
> hi stefan,
> 
> > For what Mathew needs, I believe separate workspaces and a separate
> > repository system might be a good idea.
> > Here is why, he says that he is in a portal environment. That means
he
> > has different sites with different sets of users. None of these
sites
> > have data that needs to mingle.
> i agree if two applications don't share anything you need completely
> separate repositories.
> separate repositories and separate workspaces are a different
> issue though.
> 
> separate repositories means that you do not share
> nodetypes, namespaces or versionhistories or any admin features.
> 
> i would argue that matthew will share the same nodetypes across his
> different applications therefore or users (superusers or powerusers)
> that oversee multiple sites and need to for example create new sites.
> but of course i don't really know that.
> 
> anyway, it is important to clearly distinguish the requirements for
> separate
> "workspaces" and separate "repositories".
> 
> 
> > What if these sites are set up as
> > completely different webapps? So each webapp would have its own
> > repository, db, index and everything else. They could be accessed as
> > http://domain.com/site1 and http://domain.com/site2.
> > Would this make sense?
> i agree that separate repositories may be feasible.
> since our wcm customers are running large numbers of public facing
> websites
> off a single repository workspace and i have not found a drawback with
> that
> architecture yet (on the contrary) i would probably in the future also
> choose
> the same architecture again.
> 
> regards,
> david


Mime
View raw message