Ack. As Dominique mentioned, there are cases where you want to share scripts between "tenants". For example a partner hosting multiple customers with a set of common components/resource types.
If you want to model that with a custom resource resolution, you will build the same system that's already there: Who says that tenant configuration that you'll need (defining /content/acme is tenant "acme" and is only allowed to execute stuff from /apps/acme, /libs/* and maybe /apps/common etc.) is safer than setting up resource types as now? Cheers, Alex On 12.08.2014, at 04:38, Dominik Süß <dominik.su...@gmail.com> wrote: > Hey Stefan, > > just to add my 2 cents on constraints for a tenant: > * In both cases the tenant could be identfied by one or more branches in > the repo that can be linked to exactly one tenant. > * In cases of Tenant Inheritance (as described in the Massive Multi Site > Scenario) the returned Tenant would be the most concrete Tenant but could > be identified as "subtenant" (e.g. /content/maintenant/subtenant maps to > "subtenant" which can be identified to be anchestor of "maintenant") > * Contentsharing could happen on two levels > ** Inheritance (Subtenant can always access resources from anchestors or in > last resort the platform - but is most probably not allowed to write there) > ** Synching/Sharing (Master-Slave or bidirectional syncing of Resources, so > content virtually lives within the tenants content) > > I don't think it is a good idea to bind Resource Resolution and therefore > scripts to a tenant since I can see the issue comming that a second tenant > needs to be set up with exact the same scripts. I would define a mapping > where Applicationpaths can be mapped to a tenant and the Searchpath lookup > adds those paths dynamically to a tenant. This has the advantage that it is > possible to define tenant by tenant which applicationextension will be made > available to them. > > Best regards > Dominik > > > > > > On Tue, Aug 12, 2014 at 12:43 PM, Stefan Seifert <sseif...@pro-vision.de> > wrote: > >> i created a first draft of a wiki page where i tried to collect the >> different views of and requirements for multitenancy of the recent >> discussions: >> https://cwiki.apache.org/confluence/x/So2uAg >> >> i coined new names for the two scenarios "Virtual Hosting" and "Massive >> Multi Site" >> >> we should decide first which of the requirements we can target in a first >> phase, and which are more complex or even not solvable within the current >> architecture. and - of course - what is already fulfilled by the current >> sling tenant implementation. >> >> my interest is currently primary in the "massive multi site" scenario, and >> especially the configuration part in it. >> >> stefan >>
