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 >
