sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seifert <sseif...@pro-vision.de>
Subject RE: [RT] Context-Aware Services - Multitenancy for SPI implementations
Date Mon, 18 Sep 2017 09:47:41 GMT

>-----Original Message-----
>From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]
>Sent: Tuesday, September 12, 2017 8:31 PM
>To: dev
>Subject: Re: [RT] Context-Aware Services - Multitenancy for SPI
>implementations


>In my upcoming adaptTo talk I'll mention making resource types
>multi-tenant, by prefixing them with a "web property" identifier,
>something like com.example/blog/page where the prefix is added
>automatically based on the content path. Requires making the search
>path dynamic but I've done that in another prototype, SLING-4386.
>
>I haven't implemented that in my prototype though, it's just an idea so
>far.
>
>But I've been thinking for some time that using the resource
>resolution logic for more than just scripts could be useful, without
>inventing new mechanisms.
>
>I don't want to derail your prototype, I don't have concrete use cases
>myself , just wanted to note that my experimentation led me to similar
>conclusions in other places, so a common mechanism for "locating
>things based on the script resolution logic" might be useful. In your
>case it might be "locating a ContextAwareService", but maybe resource
>types do not apply for that case.

this is an interesting concept, i need to think more about it if this could be used for my
use cases as well. 
currently i'm thinking selecting on base of resource types would match not all of them, e.g.
a SPI for configuring a "cross-cutting concern" which is used by multiple components, using
resource types from a mix of applications and central libraries - but for all of them a tenant-specific
implementation should be choosen.

but it makes definitely sense to try to align these related approaches, perhaps we find a
common solution. maybe we will find some time on the adaptTo for further brainstorming.

stefan
Mime
View raw message