Hi Dominik,
Thanks for this link, but I'm still confused about scoping. Looking at
http://wcm.io/config/api/usage-api.html, it seems like a Configuration
object is essentially just a ValueMap. In a non-trivial application,
it seems like you need some kind of namespace for configuration
properties. For example, let's say that I'm integrating with multiple
OAuth services. I thus have multiple configuration properties which
are natually named 'secretKey'. Do I need to prefix these property
keys with the service name, e.g. "facebook.secretKey" and
"linkedin.secretKey"? I would expect that I could have a Map of Maps
so I could say something like
configuration.get("facebook").get("secretKey") ?

How is this embodied in the API? Are "facebook" and "linkedin" applications?

Justin

On Tue, Oct 14, 2014 at 5:13 AM, Dominik Süß <dominik.su...@gmail.com> wrote:
> Hi everyone,
>
> I guess people yet just had no chance to dig into the proposal since there
> are a lot of scenarios adressed throught this proposal. As far as I
> understood the API & SPI the main driver for this proposal is the massive
> multisite scenario as described in the mentioned wiki page. Key aspects
> seem to be to get an aggregated context specific view for a configuration
> while lookup aspects (such as where to look up the configs and how
> inheritance is solved) are designed in a pluggable way that allows to
> implement application specific behavior.
>
> From offlist discussions I know that there might be some confusion around
> how the scoping should work so I just wanted to highlight the mentioned
> link [3] that might eliminate confusion around the wording (especially
> appliation).
>
> IMHO it would be an extremely valuable addition providing sufficient
> flexiblity to solve all the cases I do have in mind while establishing one
> unified methodology to deal with all the non osgi configuration without
> rewriting casespecific lookup (boilerplate) code over and over again.
>
> Best regards,
> Dominik
>
> [3] http://wcm.io/config/api/terminology.html
>
>
>
> On Sat, Oct 4, 2014 at 1:55 AM, Stefan Seifert <sseif...@pro-vision.de>
> wrote:
>
>> p.s. url [1] is wrong - it should be
>> https://cwiki.apache.org/confluence/x/So2uAg
>>
>> -----Original Message-----
>> From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>> Sent: Saturday, October 04, 2014 1:54 AM
>> To: dev@sling.apache.org
>> Subject: [PROPOSAL] Context-specific configuration for Apache Sling,
>> Multitenancy
>>
>> this proposal is about context-specific configuration, that means
>> configuration that cannot be stored as OSGi configurations. OSGi
>> configurations are always system-wide, so they are not well-suited for
>> storing configurations per context e.g. site, region or tenant. this is
>> related to the multitenancy discussion on this list, see [1] for a summary
>> of the past discussion.
>>
>> we've implementation a solution for this and are currently thinking about
>> donating it to Apache Sling. a documentation of what is currently
>> implemented is at [2]. the most relevant pages you should read are [3],
>> [4], [5], [6]. the implementation is based on the requirements from [7],
>> although not all that is listed on that page is implemented currently (but
>> a good deal of it). source code is at [8], a sample application at [9].
>>
>> the current implementation is targeted to a specific sling-based CMS - but
>> besides the configuration editor and the parameter persistence provider it
>> does not depend on the CMS API but only on the Sling APIs, being
>> technically suited to be donated to Apache Sling. it's already published
>> under apache license 2.0.
>>
>> i'm interested if there is more need in the community for solving the
>> requirements i've listed, and the solutions we have implemented for it. and
>> if there are other sling committers who want to take part in its
>> development and enhancement as well. although we're using the current
>> implementation from wcm.io already in our projects nothing of it's
>> current architecture is carved in stone and i'm open to broaden the scope
>> of requirements it should support.
>>
>> WDYT?
>>
>> stefan
>>
>>
>> [1] https://cwiki.apache.org/confluence/x/zJBcAg
>> [2] http://wcm.io/config/
>> [3] http://wcm.io/config/api/terminology.html
>> [4] http://wcm.io/config/api/usage-api.html
>> [5] http://wcm.io/config/api/usage-spi.html
>> [6] http://wcm.io/config/editor/usage.html
>> [7] https://wcm-io.atlassian.net/wiki/x/HIAH
>> [8] https://github.com/wcm-io/wcm-io/tree/master/config
>> [9] http://wcm.io/samples/config-sample-app/
>>
>>

Reply via email to