Hi Stefan, thanks for sharing your thoughts,
2014-08-11 15:13 GMT+02:00 Stefan Seifert <sseif...@pro-vision.de>: > > let's start with the detecting of a tenant: > > * if adapting from a resource resolver, detection by user is done. but > this implies that every user is exactly assigned to one tenant, which is - > at least in our projects - not always the case. there are always users that > have access to multiple tenants, controlled via ACLs. so this is not a 1:1 > relation, but a 1-to-many relation. > > Right, this is how the implementation currently works - the nice thing is that this is abstracted behind the adaptTo call, so it can easily be replaced with something totally different. > * if adapting from a resource a path-based detection is used. here i do > not fully understand which path is meant - the path to the content of the > tenant (e.g. /content/*), or the path to custom scripts used in script > resolution (comparable to /apps/*). i do not get the distinction from your > RT as well - you refer only to the script resolution part. but if adapting > from a resource, this is usually a content resource, not a resource > pointing to a script. > I think in this case, adapting from a content resource is meant. To be honest, I'm not sure if this is a good idea anyway - but the good thing is - as above - it's abstracted. Personally I would skip this adaption and just go with resource resolver. > in my opinion both is relevant - to be able to connect one or multiple > subtrees in the content resource hierarchy with a specific tenant, and to > allow to provide tenant-specific script overlays. > in a 1:1 releation user->tenant the content dependency could be modeled > via ACLs, but if you have one user that can access multiple tenants this > does not work. > > I think, the way I wanted it actually to describe is, that there is a 1:1 relation between a request and a tenant. All tenant aware components simply adapt the resource resolver to Tenant and get the tenant. Regardless of how the mapping is done. > besides this for our usecases the option to provide tenant-specific script > resources has no high prio. much more importance is the possibility to > create tenant-specific configuration. this may apply OSGi services, which > currently support only one global configuration (ore one per runmode > combination). on the other side this applies to other application-specific > business logic which should behave differently from site to site or from > tenant to tenant. > Right, the use cases we have are per tenant scripts right now :) But I totally agree that per tenant OSGi configuration/bundles etc would be nice. A broad answer to this would be subsystems - although I'm not sure if it would help in all cases. > > btw. we should perhaps first start to define what we mean with the term > "tenant". this much-used and overloaded term might be a source of confusion > as well. in my view a tenant is in its smallest form e.g. one "site" > (homepage and all content pages below), perhaps plus a separate area for > media assets. but a tenant can also be a huge entity consisting of a lot of > sites and other content. because even for a huge tenant there might be the > need for different configuration for different sites/areas of the content > we are currently thinking if we even need support for nested tenants, which > allow a configuration parameter inheritance between the inner and outer > tenants, up to the global level of OSGi configurations. > > for the configuration topic perhaps a separate RT should be started, but > it's closely related to a tenant concept. > Right, it's overloaded. I think the wikipedia definition at [1] is what we mean. Although this needs to be mapped to Sling powered application. In our case we need partitioning of content, resource resolving and script resolution. With fully multi tenant support this would include OSGi configs and bundles. So, this would fit your site definition even for large sites. [1] http://en.wikipedia.org/wiki/Multitenancy Regards Carsten > > stefan > > > > >-----Original Message----- > >From: Carsten Ziegeler [mailto:cziege...@apache.org] > >Sent: Monday, August 11, 2014 1:18 PM > >To: dev@sling.apache.org > >Subject: [RT] Multi Tenancy > > > >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 > >cziege...@apache.org > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
