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