Thanks for the replies so far, appreciate it. One of the reason for multi-subscriber/multi-repository, is the system will be a multi-tenant system. Managing access just via security will involve quite a bit of security and access management. And you have to get it right so you don't allow subscriber A to look at subscriber B's data. Also, when you turn on versioning, that is repo global, therefore more security management.
On Fri, Oct 21, 2011 at 9:09 AM, Justin Edelson <[email protected]>wrote: > Indeed, but that's not to say that a repository per subscriber is :) > Access Control is the way to do what you want to do. > > That said, AFAIK, there's no reason you can't have multiple > repositories per VM as long as each point to a different directories > and (if you're using a database-backed pm) different table spaces. > It's just not typical and seems very heavyweight for what you want to > do. > > Justin > > 2011/10/21 Fabián Mandelbaum <[email protected]>: > > I thought that different-workspaces-for-each-subscriber (read: user) > > was discouraged by David's Model Rule #3: > > > > http://wiki.apache.org/jackrabbit/DavidsModel > > > > On Fri, Oct 21, 2011 at 10:45 AM, Gustavo Henrique Orair > > <[email protected]> wrote: > >> What about using different workspaces for each subcriber? > >> > >> > >> 2011/10/20 Ardaman Grewal <[email protected]> > >> > >>> I am trying to design and implement a version-able document system that > is > >>> meant for multiple subscribers of the system. Data for each subscriber > has > >>> to be isolated from each other. A Web app will provide REST API for the > >>> client applications to access data. Web app will also handle some of > the > >>> security and subscription aspects of the subscribing users. I have been > >>> considering Jackrabbit for data management and versioning backed by a > >>> relational database. For the web app, thinking of hosting it in Tomcat. > >>> Hopefully, the following figure comes through properly formatted. In > case > >>> it > >>> doesn't, it shows a web app which layers a REST api on top of multiple > >>> (separate) JR repositories. > >>> > >>> Is this a correct approach? Is Jackrabbit intended to be used like this > or > >>> am I in the weeds? Any other suggestions. > >>> > >>> Thank you very much. > >>> > >>> > >>> > >>> +-----------+ > >>> | | > >>> +------+ | | > >>> +--------------+ > >>> +------>|Repo A|<---------->| Web |<--------> | Subscriber > A | > >>> | +------+ | App | > +--------------+ > >>> | | Exposes | > >>> | | REST | > +--------------+ > >>> | +------+ | Svcs |<--------> | Subscriber > B | > >>> +------>|Repo B|<---------->| | > +--------------+ > >>> | +------+ | | > >>> | | | > >>> | +-----------+ > >>> \|/ > >>> +------------+ > >>> | one or more| > >>> | RDMS Store | > >>> +------------+ > >>> > >> > > > > > > > > -- > > Fabián Mandelbaum > > IS Engineer > > >
