2016-07-19 13:57 GMT+02:00 Mark Struberg <[email protected]>:
> Thanks Anatole, It’s a start. > > But this only covers the consumer part, or did I miss something? > What about the SPI part? > > Do you think we can live without a way to declare where the configuration > comes from? > Would this be totally up to the container vendor? > How to provide default configuration inside e.g. a jar? > > @Romain: yes, I also think get(String) is enough, rest is probably sugar. > The getProperties() actually makes mostly sense on the ConfigSources (e.g. > for an admin/control page) but probably not on the final Configuration > instance. > > Kind of agree but for me getProperties() depends the source and each source can get its own admin "repository" so I think it doesn't belong to a generic API yet - or it means you need to put write method there as well and I'm not sure we are ready for that or want that. > txs and LieGrue, > strub > > > > Am 19.07.2016 um 13:38 schrieb Romain Manni-Bucau <[email protected] > >: > > > > Ok for ConfigException, ConfigProvider with some rework (see end of the > > mail) is ok however I think that: > > > > - Configuration (as a core API) shouldn't get more than get(String). The > > "or default" is sugar we'll add on top of that anyway and getProperties() > > implies you can list all entries which can not be possible so I wouldn't > do > > it in the main core part (DS did it for historical reasons and I think > > today it is not the best it could have done) > > - I tend to think Filter and Source can be part of the core cause > otherwise > > you have an entry supplier without any way to provide values. > > > > > > Then about provider: what about just applying bean validation model > blindy > > first (provider to load a factory to create through a builder API or > > through default loading mecanism an instance - of Configuration for us)? > I > > don't think we can get rid of the provider layer cause it will likely use > > ServiceLoader - even in OSGi since it will be part of the impl so fine - > > and the provider will then use what is adapted to its env to load other > SPI > > like sources/filters. > > > > So it would make a core of (feel free to change name): > > > > - Configuration { > > String get(String); > > static Configuration buildDefaultConfiguration() { > > > byProvider(...loadDefault()...).withSources(...loadDefaults()...).withDeciphers(...loadDefaults()...).build(); > > } > > static BootConfig byProvider(String); > > } > > - ConfigurationProvider { > > Configuration build(BootConfig) > > } > > - BootConfig { > > withSources(sources...); > > withDeciphers(filters...); > > Configuration build(); > > } > > - ConfigurationSource { String get(String); String name(); } // but don't > > impl Configuration for future > > - ConfigurationDecipher { String decipher(String); String name(); } > > > > > > wdyt? > > > > > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > > <http://www.tomitribe.com> | JavaEE Factory > > <https://javaeefactory-rmannibucau.rhcloud.com> > > > > 2016-07-19 13:18 GMT+02:00 Werner Keil <[email protected]>: > > > >> Sounds like a plan. > >> > >> Not sure, if a "general" top level configuration type specialized for > >> String allows extending it in another model without some restrictions, > but > >> if the java.util.Properties like get(String) is of minimalistic use, > e.g. > >> where it's backed by "good old Properties" anyway why not. Extending it > it > >> with a flexible type-system would still be possible. > >> > >> Supplier<String> sounds Java SE 8, so in an API that works both in Java > SE > >> 6/7 or Java ME 8 that cannot exist. > >> > >> If a type like ConfigurationProvider is optional, then it would be > better > >> to put it to another package. Makes building smaller modules easier > IMHO, > >> otherwise you probably have to use filtering and "Maven magic" to ensure > >> only the mandatory or core types are packaged for a "minimal" profile or > >> situation while everything is built for a "full" scope. > >> > >> Werner > >> > >> > >> > >> On Tue, Jul 19, 2016 at 12:39 PM, Anatole Tresch <[email protected]> > >> wrote: > >> > >>> For me a point is that I would like to see the API being complete, > >> meaning > >>> all I need is the API to get a Configuration. Using Java 8 I don't need > >> it, > >>> so I can provide the ConfigurationProvider for Java 7 only. > >> ConfigOperator > >>> and -Query are only there for Java 7, they easily vould be removed from > >> the > >>> API as well. > >>> But talking about minimal: a*lso the idea of organizing configuration > as > >>> property sources is already a design decision the API should not care > >> about > >>> IMO*. So being really minimal, we need: > >>> > >>> - Configuration (interface) > >>> - ConfigException (exception) > >>> - ConfigurationProvider (optional) > >>> > >>> The key here is Configuration. We agree IMO to provide *single* key > >> access > >>> for String values. IMO people also expect access to non-String values, > >> but > >>> this must not be part of the core Configuration interface since it > could > >>> easily be added as a facade functionality for example, so it can be > >>> realized as an extension module! > >>> Accessing a Map<String,String> of properties IMO, and also from user > >>> feedback, is a wanted functionality. In most cases also the result can > be > >>> well calculated and further functionality added on top that most people > >>> expect from a Configuration solution. This is also what we have done in > >> the > >>> current source tree (see tamaya-functions module). > >>> > >>> So my proposal would be: > >>> > >>> - reduce the API to these 3 artifacts (including ConfigProvider - it > >>> doesnt hurt and makes migration from Java 7 to 8 much easier). > >>> - Remove type support from Configuration, it can be added in a > >> separate > >>> module > >>> , which is not too much change needed). > >>> . > >>> - discuss how the ConfigurationProvider loads the Configuration > >>> instance to be returned (service loader, OSGI service). > >>> - move all the rest of artifacts into separate modules. This also > >>> includes the DS inspired parts of PropertySource handling currently > in > >>> the > >>> core module. > >>> > >>> > >>> People already using deltaspike can easily plugin in the DS logic > without > >>> having to rewrite anything and start using the new API. In CDI > >>> Configuration can be determined from using the CDI context (os > something > >>> else in stages, where CDI is not yet loaded). Same story for Spring and > >>> more. > >>> > >>> This is basically what I proposed in the* tamaya-next branch*: So our > >>> complete core API fits into half a page! > >>> > >>> public interface Configuration { > >>> String get(String key); > >>> default String getOrDefault(String key, final String > defaultValue){...} > >>> default String getOrDefault(String key, Supplier<String> > >>> defaultValueSupplier){...} > >>> Map<String,String> getProperties(); > >>> } > >>> public final class ConfigurationProvider { > >>> [...] > >>> Configuration getConfiguration(){ > >>> // tbd > >>> } > >>> } > >>> public class ConfigException extends RuntimeException{ > >>> private static final long serialVersionUID = -5886094818057522680L; > >>> public ConfigException(String message){ > >>> super(message); > >>> } > >>> public ConfigException(String message, Throwable t){ > >>> super(message, t); > >>> } > >>> } > >>> > >>> J Anatole > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> 2016-07-19 9:08 GMT+02:00 Werner Keil <[email protected]>: > >>> > >>>> tamaya-api-0.2-incubating.jar is just 30 kb right now. > >>>> While the exact set of methods is questionable in the "design study" > >>> (just > >>>> leave it as that and thanks to EC members like myself or Ben there's > no > >>>> further damage done by the way it was presented, we're not talking > >> about > >>>> JCP aspects here now ;-) a minimalistic approach may leave > >> Configuration > >>>> and ConfigException pretty much the only core elements. Not even sure > >>> about > >>>> the *Provider. As the name suggests it could be in an SPI, take JCache > >>>> (where only its Caching static facade mixes the two and makes clean > >>>> separation impossible, CacheProvider is in an SPI package though) > >>>> > >>>> *Operator and *Query feel a bit redundant and both can be seen as > >>> optional. > >>>> Especially for implementations based on Java 8 one could probably > stick > >>> to > >>>> Function<Configuration, Configuration> or similar to accomplish that. > >> If > >>>> Tamaya needs a Java 7 compatibility layer (it'll take years before > >>>> especially the Enterprise sector will fully adopt even Java SE and EE > >> 7, > >>> I > >>>> work there all the time and see what's used;-) then it could be in a > >>>> different package/jar, but doesn't have to be in a core API. > >>>> > >>>> Cheers, > >>>> Werner > >>>> > >>>> > >>>> On Tue, Jul 19, 2016 at 3:57 AM, Mark Struberg > >> <[email protected] > >>>> > >>>> wrote: > >>>> > >>>>> Then see it as the smallest possible core. It has only 30 kByte > >> (api+RI > >>>>> jars). > >>>>> It even works on ME or Android. > >>>>> > >>>>> LieGrue, > >>>>> Strub > >>>>> > >>>>>> Am 19.07.2016 um 01:00 schrieb Werner Keil <[email protected] > >>> : > >>>>>> > >>>>>> We're not talking about the API when it comes to Spring, OSGi or > >> even > >>>> CDI > >>>>>> support. Same for say a YAML module, etc. > >>>>>> Those are implementation specific. > >>>>>> > >>>>>> The more modular and fine-grained the API (of Tamaya) can get, the > >>>>> better. > >>>>>> > >>>>>> CDI has to learn that with V2 only, but for relatively new JSRs or > >>>> modern > >>>>>> projects it should be considered right from the start. > >>>>>> The most basic core API may or may not work even on Java ME > >> Embedded. > >>>>>> JSR 363, which has a core of only 4 mandatory core types plus 3 > >>>>> exceptions. > >>>>>> If put in a separate JAR those would only take around 5k. Fits even > >>> the > >>>>>> smallest Java ME device out there. You may not always be able to > >> cut > >>>>> things > >>>>>> as small in "Server Land" but getting the idea and trying to be > >>> modular > >>>>>> even before the JDK starts to enforce that with Java 9 is the right > >>>>>> approach. > >>>>>> > >>>>>> > >>>>>> On Mon, Jul 18, 2016 at 11:13 PM, Romain Manni-Bucau < > >>>>> [email protected]> > >>>>>> wrote: > >>>>>> > >>>>>>> Le 18 juil. 2016 23:04, "Werner Keil" <[email protected]> a > >>>> écrit : > >>>>>>>> > >>>>>>>> Tamaya already works with e.g. Spring despite Spring Framework > >>>> offering > >>>>>>>> Config functionality of its own;-) > >>>>>>>> > >>>>>>> > >>>>>>> Yes but libs cant rely on spring config api without bringing back > >>>> spring > >>>>>>> core > >>>>>>> > >>>>>>>> So as there are other config solutions at Apache like Commons > >>> Config, > >>>>>>>> exclusing CDI because DeltaSpike already uses it sounds odd. > >>>>>>>> > >>>>>>> > >>>>>>> Commons config has no link afaik since it provides nice low level > >>> impl > >>>>> but > >>>>>>> no good end user api/integration. It is also too opiniated to be > >>> good > >>>>> for a > >>>>>>> spec since it has a lot of core methods making it hard to > >> integrate > >>>> with > >>>>>>> all frameworks without limitations. > >>>>>>> > >>>>>>> That is why tamaya core should be minimal IMO. > >>>>>>> > >>>>>>>> There are even Apache projects like Tapestry that still offer > >> their > >>>> own > >>>>>>> DI > >>>>>>>> mechanism beside a JSR 330/CDI one, so I hope you're not > >> suggesting > >>>>>>> Tamaya > >>>>>>>> should do the same just to "avoid" DeltaSpike?;-O > >>>>>>>> > >>>>>>> > >>>>>>> I'm saying that tamaya core should be light enough to work with > >> any > >>>>> context > >>>>>>> impl and never conflict with them, ie not implementing another > >>>> context, > >>>>> ie > >>>>>>> providing built Config but not store them itself. > >>>>>>> > >>>>>>>> > >>>>>>>> On Mon, Jul 18, 2016 at 10:53 PM, Romain Manni-Bucau < > >>>>>>> [email protected]> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Trying to get back on track... > >>>>>>>>> > >>>>>>>>> If Tamaya targets CDI it will compete in a useless manner with > >> DS > >>> or > >>>>>>> any > >>>>>>>>> specific config API, if it targets contextuality it will with > >> any > >>>> IoC, > >>>>>>> if > >>>>>>>>> it targets coercing it will as well with one or both of previous > >>>>>>> points. > >>>>>>>>> > >>>>>>>>> So IMO Tamaya API should be as Mark explained about handling > >>> sources > >>>>>>> and > >>>>>>>>> filters to build on Config which can provide string access - and > >>> not > >>>>>>>>> properties cause it shouldnt be listable by default IMO. > >>>>>>>>> > >>>>>>>>> In term of API design I would align it on bval - a factory with > >> a > >>>>>>> builder > >>>>>>>>> or a default loading to get a Config. It is core for me. Mark > >>> likes > >>>> to > >>>>>>>>> count classes: factory + config + provider + source + source > >>>> provider > >>>>> + > >>>>>>>>> filter (we can merge few of them using j8, not sure it is good > >> but > >>>>>>> would > >>>>>>>>> work). > >>>>>>>>> > >>>>>>>>> Once we agree on that we will have to discuss on top of that: > >>>>>>>>> > >>>>>>>>> - integrations > >>>>>>>>> - injections (injection points vs proxy Bean) > >>>>>>>>> - coercion > >>>>>>>>> - default impls > >>>>>>>>> - .... > >>>>>>>>> > >>>>>>>>> But making the API small, strong and usable by all is important > >>> IMHO > >>>>>>>>> > >>>>>>>>> Le 18 juil. 2016 22:41, "Werner Keil" <[email protected]> a > >>>> écrit > >>>>>>> : > >>>>>>>>> > >>>>>>>>>> Sorry to dissapoint you, but I was involved at least in Tamaya > >>>> before > >>>>>>>>>> Anatole even proposed it. > >>>>>>>>>> I was nearly asked to give the presentation on what later > >> became > >>>>>>> Tamaya > >>>>>>>>> by > >>>>>>>>>> Mike Keith when he was stuck in heavy Monsoon rain at GIDS > >>> 2011;-) > >>>>>>>>>> > >>>>>>>>>> I know what Commons Config, Tamaya or DeltaSpike can be used > >> for. > >>>> And > >>>>>>>>>> helped clients who found e.g. DeltaSpike too complex and > >>> overloaded > >>>>>>> by > >>>>>>>>>> contributing to their in-house CDI-based configuration > >> framework > >>>>>>>>> "inspired" > >>>>>>>>>> by it. So Tamaya isn't the only example of API that some find > >>> "too > >>>>>>>>> much"... > >>>>>>>>>> > >>>>>>>>>> Werner > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Mon, Jul 18, 2016 at 10:08 PM, Mark Struberg > >>>>>>>>> <[email protected] > >>>>>>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> It seems you do not yet understand the mechanics behind > >>> DeltaSpike > >>>>>>> and > >>>>>>>>>>> Tamaya. Let me elaborate: Properties (and commons-config1&2 as > >>>> well > >>>>>>> for > >>>>>>>>>>> that matter) only handle information from a SINGLE file. > >>>>>>>>>>> > >>>>>>>>>>> Whereas the ConfigSource approach abstracts that into an > >> ordered > >>>>>>> stack > >>>>>>>>> of > >>>>>>>>>>> _multiple_ such 'sources'. And such a > >>> ConfigSource/PropertySource > >>>>>>> also > >>>>>>>>>>> doesn't need to be a single property file. It can be anything > >>>> which > >>>>>>>>> gives > >>>>>>>>>>> access to configuration information. > >>>>>>>>>>> > >>>>>>>>>>> So yes, it should imo be as easy as property files - even > >>> easier. > >>>>>>> But > >>>>>>>>> it > >>>>>>>>>>> is not a _single_ file but many of them. And not only property > >>>>>>> files > >>>>>>>>> but > >>>>>>>>>> a > >>>>>>>>>>> freely extensible bunch of different such configuration > >> sources! > >>>>>>>>>>> > >>>>>>>>>>> I hope you _now_ see the huge difference. > >>>>>>>>>>> Regarding type-safety: I already wrote that twice: check out > >>>>>>>>> ConfigValue. > >>>>>>>>>>> (copying the example again): > >>>>>>>>>>> > >>>>>>>>>>> --- > >>>>>>>>>>>> This allows for things like > >>>>>>>>>>> > >>>>>>>>>>>> ConfigValue<Integer> reloadAfterCfg = > >>>>>>>>>>>> > >> ConfigProvider.getConfig().access("myproject.mydb.reloadAfter") > >>>>>>>>>>>> .as(Integer.class) > >>>>>>>>>>>> .withDefault(1000) > >>>>>>>>>>>> .cacheFor(5, TimeUnit.MINUTES) > >>>>>>>>>>>> .evaluateVariables(true) > >>>>>>>>>>>> .withLookupPath(config.getValue("myproject.dbvendor"), > >>>>>>>>> projectStage); > >>>>>>>>>>>> > >>>>>>>>>>>> And later use > >>>>>>>>>>>> reloadAfterCfg.getValue()--- > >>>>>>>>>>> > >>>>>>>>>>> LieGrue, > >>>>>>>>>>> strub > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Monday, 18 July 2016, 21:53, Werner Keil < > >>>> [email protected] > >>>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>>>> To consider possible simplification and common denominators, > >> it > >>>>>>> seems > >>>>>>>>>>> good to have a look at Tamaya's base interface: > >>>>>>>>>>> > >>>>>>> > >>> http://tamaya.apache.org/apidocs/org/apache/tamaya/Configuration.html > >>>>>>>>>>>> and > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>> > >> > https://commons.apache.org/proper/commons-configuration/apidocs/org/apache/commons/configuration2/ImmutableConfiguration.html > >>>>>>>>>>>> > >>>>>>>>>>>> they have at least some very basic methods in common. Leaving > >>> the > >>>>>>>>> order > >>>>>>>>>>> of key or type aside. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> In your proposed Config interface I only saw a > >>>>>>>>>>>> String get(String) method, but for that sorry, we could just > >>>> stick > >>>>>>> to > >>>>>>>>>> the > >>>>>>>>>>> good old Properties and forget about the whole thing ;-| > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> A default or convenience method (what Commons Config 2 calls > >>>>>>>>>> getString()) > >>>>>>>>>>> why not, but without type-safe yet extensible getters, there > >> is > >>>>>>> little > >>>>>>>>>>> value to create a new API with more or less the same value > >>>>>>> (literally) > >>>>>>>>>> than > >>>>>>>>>>> java.util.Properties. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> I know you're on the CDI EG, other than that, not sure, > >> which > >>>>>>> others > >>>>>>>>>>> (according to JCP.org, not mailing lists or other forms of > >>>>>>>>> contribution) > >>>>>>>>>>>> Being on both sides (EG and EC) in many cases, I am used to > >>>>>>> question > >>>>>>>>>> JSRs > >>>>>>>>>>> and their Spec Leads, so it's not bad if this happens before > >> any > >>>> of > >>>>>>>>> that > >>>>>>>>>>> was filed or sonsidered towards a JSR. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Although there had been 2 attempt (one even by Adam Bien at a > >>>> very > >>>>>>>>> early > >>>>>>>>>>> stage of his efforts in the JCP) JSR 377 is an example for a > >>>>>>> seemingly > >>>>>>>>>>> premature JSR proposal. And unless Andres does some "miracle" > >> it > >>>>>>> may > >>>>>>>>>> likely > >>>>>>>>>>> be shut down by the EC with the next Renewal Ballot. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> So JCP.next introduced a few measures to avoid "neverending > >>> JSRs" > >>>>>>> like > >>>>>>>>>>> 107 or 310 now, but sometimes it isn't a bad thing to wait or > >>> file > >>>>>>> it > >>>>>>>>>> based > >>>>>>>>>>> on experience by one or several Open Source projects. > >> Hibernate > >>>> was > >>>>>>>>> one, > >>>>>>>>>>> but considering the JPA RI is based on TopLink (now > >> EclipseLink) > >>>> it > >>>>>>>>>>> certainly isn't the only project behind what became JPA > >> either. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Cheers, > >>>>>>>>>>>> Werner > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Mon, Jul 18, 2016 at 9:15 PM, Mark Struberg > >>>>>>>>>> <[email protected]> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Yes Werner, we know. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> But nonetheless Hibernate managed to > >>>>>>>>>>>>> > >>>>>>>>>>>>> a.) get the spec on the ground pretty efficiently > >>>>>>>>>>>>> b.) implemented the JPA specification on top of their own > >>> logic > >>>>>>> in a > >>>>>>>>>>> timely fashion. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> As you know I'm contributing to a number of specifications > >> as > >>> an > >>>>>>>>>>> _active_ JCP EG member myself for many years now, so I really > >>> know > >>>>>>> all > >>>>>>>>>> this > >>>>>>>>>>> stuff! > >>>>>>>>>>>>> > >>>>>>>>>>>>> On the original topic: if I say '5 interfaces' than those > >>> don't > >>>>>>> need > >>>>>>>>> to > >>>>>>>>>>> be exactly the ones I proposed. I also don't care whether we > >>> call > >>>>>>> them > >>>>>>>>>>> ConfigSource or PropertySource (as example). All I like to do > >> is > >>>> to > >>>>>>>>>> review > >>>>>>>>>>> and clean up the API. After all this is a community decision. > >>> If a > >>>>>>>>>> majority > >>>>>>>>>>> of Tamaya committers say I'm nuts and the current API is fine, > >>>> then > >>>>>>> be > >>>>>>>>>> it. > >>>>>>>>>>> Otoh if the majority is to do the cleanup then we should do it > >>>>>>>>> properly. > >>>>>>>>>>>>> > >>>>>>>>>>>>> LieGrue, > >>>>>>>>>>>>> strub > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Monday, 18 July 2016, 20:55, Werner Keil < > >>>>>>> [email protected] > >>>>>>>>>> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> Hibernate vs. JPA is also an interesting read: > >>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>> > >> > http://stackoverflow.com/questions/9881611/whats-the-difference-between-jpa-and-hibernate > >>>>>>>>>>>>>> Like Tamaya, Apache Commons Config or other config > >> solutions, > >>>>>>>>>>> Hibernate was > >>>>>>>>>>>>>> there before JPA. Its creators were involved as well as > >> many > >>>>>>> others > >>>>>>>>>>> (even > >>>>>>>>>>>>>> Apache or Novell;-) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Werner > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Mon, Jul 18, 2016 at 7:56 PM, Gerhard Petracek < > >>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> before i vote, i would like to hear if there is a real > >>>>>>> blocker > >>>>>>>>> for > >>>>>>>>>> a > >>>>>>>>>>>>>>> simpler api (besides collections). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> regards, > >>>>>>>>>>>>>>> gerhard > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> *Anatole Tresch* > >>> PPMC Member Apache Tamaya > >>> JCP Star Spec Lead > >>> *Switzerland, Europe Zurich, GMT+1* > >>> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * > >>> *Twitter: @atsticks, @tamayaconf* > >>> > >> > >
