What I can say is that I will provide unit tests for all parts I have added (I am well aware of that). Any helps, of course, is appreciated ;)
-----Original Message----- From: Mark Struberg [mailto:[email protected]] Sent: Donnerstag, 22. Januar 2015 15:39 To: [email protected] Subject: Re: PropertyQuery we can certainly do a clean review without [] support now. But there are quite a few important things missing atm imo. 1.) TCK or better unit tests in general. 2.) the Java7 impl needs to get implemented 3.) a REAL in depth license and IP clearing. We really need to do that _before_ our first release. LieGrue, strub > On Thursday, 22 January 2015, 15:29, Romain Manni-Bucau > <[email protected]> wrote: > > well why I want to step back is just cause we slowly leave config > field and we are implementing a storage solution. There are already > numerous projects doing it at apache - even if they can sometimes > mandate some infra - so we should stick to the first goal of tamaya. > > I also not fully agree with the basis - in particular the SPI to be > clear - we have ATM. > > To sumamrize a first release with: > 1) SPI ("provider" + property source) > 2) basic merge/conflict policy > 3) String read API > 4) basic convertion support > > Is far enough IMO. > > Once all of it is clear I'd like we do a release to gather feedback > then continue building on top of it - we are ATM in the tunnel ;). > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > > 2015-01-22 13:47 GMT+01:00 Tresch, Anatole > <[email protected]>: >> Hi Romain/all >> >> I think we have quite a common agreement on the basic functions designed so > far and I do not want to >> reinvent or change any of the basic mechanism. I simply come up with a > simple request to use the algorithm pattern >> for a small subset of a functionality (how the final property value is > evaluated). The usage of TypeLiteral was even your >> own proposal AFAIK, when we discussed PropertyConverters ;) ). >> >> Our current configuration model in general IMO is a very good start. It is > already so flexible that I can implement 60-70% of use cases >> I have currently in use within Credit Suisse (this is somehow my > "benchmark", which from my discussions I had during the last years > covers a >> majority of use cases when dealing with distributed and modular systems). >> >> I am sure you remember, we had a discussion on another mail thread > yesterday about Collection support. My proposal >> basically is the outcome of having played around to extend our API to > support collections based only on Map<String,String> >> only as internal PropertySource representation thus avoiding the String[] > getListProperty(String) methods. >> >> So for getting type information and define the content type of collections > we need TypeLiterals, which similarly is useful perhaps for other non > collection >> cases. Since collection entries can be defined in different property > sources, a final list may want to contain all the properties found, instead > of > overriding, >> so values of different property sources are to be combined. AFAIK you > already agreed on that UC. Hardcoding yet another strategy IMO makes >> no sense, so I would recommend use the default for all common aspects (that > is what we already have in place) and add support for adapting the default >> where it is not appropriate. Thinking on this IMO both aspects > (TypeLiterals and the collector) are the same for evaluating single property > values as well, >> so regarding that it makes no sense to model collections differently, but > extend/flexibilize the way how we can access properties in general. >> >> I tried to combine both aspects in one class, which I called PropertyQuery. > Perhaps also the name PropertyQuery is confusing. Alternates would be >> PropertyRequest, PropertyAccess,... or whatever you like, I am completely > open here ;) >> >> We can postpone that discussion, but just stopping this discussion now will > not solve anything. Also we already invested a lot of discussing collection > support, why stop here. >> We have enough time I think. We have important use cases to solve that may > affect the Configuration interface as a whole. Adding them later may be a bad > idea, so we >> should sort out these things now IMO. >> >> So I am curious to see your concrete (improvement) proposals ;), so we can > continue to see, if we end up in a common view. If so, others on the mailing > list also have a >> chance to join us again, I think. >> >> Anatole >> >> >> -----Original Message----- >> From: Romain Manni-Bucau [mailto:[email protected]] >> Sent: Donnerstag, 22. Januar 2015 09:45 >> To: [email protected] >> Subject: Re: PropertyQuery >> >> not exactly, it is different to expose MapReduce in API and to >> implement it behind another concept, ATM it is an implementation >> detail. >> >> Why I worry a bit about Query stuff is we start to leave configuration >> layer to enter backend one, not sure it does worth it *to start* - I >> understand your feature even if I never needed it but I'd really like >> we ensure our basis are solid enough before adding features on top of >> them. >> >> Said otherwise I think we should now focus on trying to make a 0.1 - >> we can add alpha to make obvious we are not done - and stop adding >> anything before being fully agree on all we have. >> >> Does it make sense? >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-22 9:39 GMT+01:00 Anatole Tresch <[email protected]>: >>> Hi Romain >>> >>> About lamba friendly I can still have a Builder that creates a query. > Works perfectly. >>> The default use cases would remain as is. Queries would just add about > 3 methods to Configuration. We get as well all the flexibility we would need > for > collection support as well ;) >>> >>> Mapreduce? Well what else is evaluating a chain of propsources by > overridding? Its already there, but hardcoded the same, which is obviously > not > flexible enough! >>> >>> - >>> Anatole Tresch >>> Glärnischweg 10 >>> 8620 Wetzikon >>> Tel +41 (43) 317 05 30 >>> - >>> Send from Mobile >>> >>>> Am 22.01.2015 um 09:11 schrieb Romain Manni-Bucau > <[email protected]>: >>>> >>>> isnt it too complicated for most common use cases (+ not that > lambda >>>> friendly cause of the 4 parameters which dont help writing readable >>>> code IMO). >>>> >>>> Functionally it works but it makes default cases "hard" > and actually >>>> you just want to implement the MapReduce pattern so maybe we should >>>> call it this way if we go this way. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-01-22 8:44 GMT+01:00 Anatole Tresch > <[email protected]>: >>>>> Dear all >>>>> >>>>> *let's think about additional use cases:* >>>>> 1) as mentioned in my last mail about collection types,* > overriding may not >>>>> always be the right resolution policy *for accessing a > configured value >>>>> (e.g. for collecting all configured values in a final > set/list). >>>>> 2) sometimes I want to define my own PropertyConverters > (already >>>>> implemented) >>>>> 3) sometimes I even would like to evaluate multiple keys taking > the result >>>>> of the first property key that returns a config property (nice > convenience) >>>>> >>>>> When we will add all this kind of aspect into Configuration, we > will end up >>>>> in a messy interface, e.g. for >>>>> String get(String); >>>>> <T> T get(String, Class<T>); >>>>> <T> T get(String, Class<T>, PropertyConverter); >>>>> >>>>> String get(String, ValueCollector); >>>>> <T> T get(String, Class<T>, ValueCollector); >>>>> <T> T get(String, Class<T>, PropertyConverter, > ValueCollector); >>>>> ... >>>>> >>>>> Obviously that does not make sense. >>>>> >>>>> Instead of I would propose, we would define a PropertyQuery, > which >>>>> basically is >>>>> >>>>> - is the same as a TypeLiteral<T> solving the type > aspects >>>>> - has a list of *keys* to be evaluated, at least one >>>>> - optionally has a ValueCollector >>>>> - optionally has a list of PropertyConverter >>>>> >>>>> With that our interface gets much leaner, but still flexible > enough to >>>>> accommodate the use cases above: >>>>> >>>>> String get(String); >>>>> <T> T get(String, Class<T>); >>>>> <T> T get(String, Class<T>, PropertyConverter); // > may be ommitted as well ? >>>>> <T> get(PropertyQuery<T> query); >>>>> ... >>>>> >>>>> This solves all use cases above and gives us an easy way to add > additional >>>>> feature, if needed (I dont see any, but who knows). Hereby > ValueCollector >>>>> would be defined as follows: >>>>> >>>>> @FunctionalInterface >>>>> public interface ValueCollector { >>>>> >>>>> /** >>>>> * Method that is called for each value returned by a > PropertySource >>>>> for the given key. >>>>> * @param currentValue the current value, including null. >>>>> * The collector should either combine > the existing >>>>> value with value from {@code currentValue} >>>>> * or replace the value in {@code > currentValue} >>>>> with {@code valueRead}, hereby returning the >>>>> * result to be used as new {@code > currentValue}. >>>>> * @param key The current key to be evaluated. >>>>> * @param newValue the new value read from the current > {@code >>>>> propertySource}, not null. >>>>> * @param propertySource The PropertySource that returned > the current >>>>> value (either as the result of a direct >>>>> * access of as a property Map > containing the >>>>> given key. The PropertySource given >>>>> * may be evaluated for additional > meta-data, how >>>>> the given values are to be combined. >>>>> * @return the value to be used for future evaluation. >>>>> */ >>>>> String collect(String key, String newValue, PropertySource >>>>> propertySource, >>>>> String currentValue); >>>>> >>>>> /** >>>>> * Default overriding collector. >>>>> */ >>>>> public final ValueCollector DEFAULT_OVERRIDING_COLLECTOR = > (k, nv, ps, >>>>> cv) -> nv; >>>>> } >>>>> >>>>> Feedback? >>>>> >>>>> Cheers, >>>>> Anatole >
