Hi Stefan, Thanks for clarifying. So is it accurate to say that your expectation that the *vast* majority of clients to use a strongly-typed Parameter object rather than doing a simple String lookup?
To me, this seems very heavyweight, but maybe I am being short sighted (or lazy). But on the other hand, if you expect clients to use Paramter objects, why support String lookup at all? Justin On Tue, Oct 14, 2014 at 11:24 AM, Stefan Seifert <sseif...@pro-vision.de> wrote: > hello justin. > > as described in [1] we currently took the design decision to have only a flat > parameter list, namespacing can and has to be done inside the parameter > names. the goal was to really support the full configuration in a single > value map. but i'm aware this may not be sufficient, but wanted to start > simple in this case. each parameter definition already has an application ID > assigned as well, so technically it would not be a problem to have a > parameter namespace per application/library that provides the parameters. > i've not found yet a nice client API solution for this - chaining two get > methods as in your example would be a solution. > > as the configuration API is designed to work with parameter constants holding > the parameter definition [2] this chaining would only be needed if the > configuration value map is accessed using string values. if using the > parameter definition constant all information is in place. parameter > definitions can have more metadata if a configuration editor is supported as > well, see example [3] resulting in [4]. > > stefan > > [1] http://wcm.io/config/api/usage-spi.html#Preconditions_and_limitations > [2] http://wcm.io/config/api/usage-spi.html#Providing_parameter_definitions > [3] > https://github.com/wcm-io/wcm-io/blob/master/samples/config-sample-app/src/main/java/io/wcm/samples/configsampleapp/config/Params.java > [4] http://wcm.io/config/editor/usage.html > > >>-----Original Message----- >>From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of >>Justin Edelson >>Sent: Tuesday, October 14, 2014 4:58 PM >>To: dev@sling.apache.org >>Subject: Re: FW: [PROPOSAL] Context-specific configuration for Apache Sling, >>Multitenancy >> >>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/ >>>> >>>>
