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/ >> >>