Hi,
we've seen a lot of different dicsussions over time wrt multi tenancy in
this list. In addition, there is the age old proposal at [1] and the tenant
module in [2] which superceeds parts of the proposal on the wiki
The current tenant module detects the tenant of a request either based on
the requested content path or the user home and provides this information
via an adapter factory for both, the resource resolver and a resource.
While this mechanism might not be sufficient, I think the key point here is
that you get the tenant by adapting the resource resolver - which actually
allows to do any detection being it path based, or based on the url, a
cookie whatever. In that sense, it seems that this design is sufficient.
When it comes to content, structuring content by tenant and using ACLs to
protect this seems to be sufficient as well.
Now, the tricky and yet unsolved part is resource and script resolution.
The idea outlined in [1] is imho obsolete because we now already have
tenant support.
I think we can add tenant support to resource resolving and script
resolution without any further api changes: both implementation can try to
adapt the resource resolver to a Tenant and then the resource resolver
implementation can use this extra information for lookups. The script
resolver uses the resource resolver anyway, the only thing needed to be
added there is that caching of script resolution should take the tenant
into account.
My suggestion is that, if the Tenant information is availabe, resource
resolving looks at three places. For example if "foo/bar" should be
resolved:
1. /tenants/{tenandId}/foo/bar
2. /apps/foo/bar
3. /libs/foo/bar
The first available will be used.
I think there is no need for several search paths per tenant or to make
this further configurable
WDYT?
Regards
Carsten
[1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support
[2] https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/tenant
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
