Hi Alex On Mon, Nov 12, 2012 at 1:07 PM, Alexander Klimetschek <[email protected]> wrote: > On 12.11.2012, at 10:55, Felix Meschberger <[email protected]> wrote: >>> Considering that most requests to websites are "anonymous", I suggest >>> that multi-tenancy support should only care about the resource being >>> requested, not about the requesting user, This also guarantees >>> consistent results for rendering. >> >> This (and the following) raise good questions. And we are not ready to >> answer them (yet) and we are not even considering per-tenant applications >> (for above stated reasons). > > I'd agree with Julian. A tenant should be dependent on something clearly > defined through the URL: e.g. the domain / Host header or a URL path, such as > domain.com/tenant. So it's essentially request-dependent, not necessarily > user or content dependent. > > Otherwise it would also overlap too much with ACLs. > >> * A ResourceResolver representing a user (just like JCR Session does) can be >> adapted to a Tenant to which the user "belongs". > > Hmm, I am not sure if a user belongs to a (single) tenant. What if a user > should be able to log into multiple tenants? For example, an agency with > multiple customers (who are tenants) or just the admin users of the site > provider.
I agree. For designing multi-tenancy support, we should assume that a user may belong to several tenants. Support for the single tenant case would thus be implied. > >> * A Resource can be adapted to a Tenant under the assumption that the >> respective Resource belongs to one of the Tenant's data areas in the >> repository. > > What if there are shared resources? You probably need the resources from a > request-specific resource resolver, which in turn handles the > request-dependent tenant resolution, so you get the right tenant from the > resource based on that, but not based on the resource's location. That's a good question, which I cannot currently answer. I think you can find arguments for rendering this resource based on the request-resource's tenant or on the resource's tenant itself. Maybe this would need to be controllable by the user of the API, e.g. by indicating the desired strategy when including a resource. > > Cheers, > Alex Regards Julian
