I see 3 problems: - allowing to hook in a custom lookup strategy and not defining a clear lookup & content model (too much magic in such things is bad, it should be obvious by just browsing the JCR, just as with resource types) - the idea of putting configurations itself under /content; configs have a different management lifecycle and ACLs - complexity of the API, Parameter<> generics just replicate the valuemap, but in what seems to me like an overengineered fashion & one that shields too much from the power of JCR, which might lead to have people invent custom string formats instead of using JCR properties; in reality, 80% of properties are strings, 10% each are boolean or integers (subjective experience stats TM :))
Cheers, Alex On 03.10.2014, at 16:53, Stefan Seifert <sseif...@pro-vision.de> wrote: > 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/ >
