Hi Romain
>well why I want to step back is just cause we slowly leave config
>field and we are implementing a storage solution.
Do we? I am only focused on config related use cases and know about what I am
talking:
- Exposing a part of the internals as API does not make a storage solution.
- Using TypeLiteral for property conversion does not have anything in common
with a storage solution.
-> So please stay on the topic and keep off things that are not relevant,
please.
>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.
-> Which is providing a configuration solution. I have well defined and well
important use cases. If you don’t have them, well...
-> I do not care (too much) what other projects do. Often others provide good
features, but also some less good ones. To argue not to repeat, what others did
IMO is useless. We should take the good things and combine it here, so we
get a good solution. And again: if you have something that disturbs you, be
explicit. Just claiming or writing down your feelings does not help anybody
here. Either you write down your concerns clearly, at the end by code, or your
input
is not much of use. It is that simple IMO. I am exposing me by writing down
and trying to do things as Java API, simply because that is the only way it
works to get
a common understanding. Sorry for the hard words here.
> 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 ;).
-> So we have a scope discussion for the new release now. IMO the current
artifacts within the API are clearly in focus for release 1 (from an API
perspective). If you want to remove anything, you should
exactly write down, WHAT should be removed and also WHY.
-> About Collection support, we may have a vote on it. Or other people here on
the mailing list should add their cents ;)
-> Gathering feedback is OK. Nevertheless we can mark the release as alpha, so
everybody is clear that things may still change.
-> And again discussing what should be part of release 1 IMO must not constrain
us to discuss on further concepts as long as the threads are clearly separated
and not too many. So help us constructively with the
discussion instead of throwing woods into our legs all the times. That
would be great!
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
