That comes down to underspecified wording on my side. I agree that there is a difference between various type formats (that what I was talking about) on the one hand and configuration flavours on the other hand.
For the configuration flavour format (ini vs properties vs json vs etc) I also feel strongly that we must not add it to _any_ of our APIs but we should of course define a few formats and locations which we support out of the box *in our documentation*. Some of them (env and jvm properties) are not even 'config files'. LieGrue, strub > On Saturday, 27 December 2014, 0:18, Romain Manni-Bucau > <[email protected]> wrote: > > 3 sounds good but dont you mix type and format? Format was more > json/xml/...than types > > Le 26 déc. 2014 23:59, "Mark Struberg" <[email protected]> a > écrit : > >> Hi! >> >> Trying to get a discussion stated WITHOUT doing tons of code which we >> probably might throw away later anyway. >> >> >> >> >> It seems we are all pretty d'accord that that primary configuration is >> done in a String/String key-value style. Native Object style as in JNDI is >> out of scope and adds too many restrictions. >> >> >> Of course there is another layer of 'Types' on top of those > Strings. E.g. >> if a user likes to configure a Date then we should define a default format >> (or rather, various ones) + eventually a 'transformer'. >> But that doesn't change the fact that _internally_ it only gets stored > as >> String. >> >> I'd suggest that we keep the core API as String only and then add >> formatters on top of that (if any). >> >> >> There are various flavours to define the various formats >> 1.) don't define it at all. Means we let the application deal with >> formatting >> 2.) Only have String/String in our API but suggest default formats in our >> documentation. >> >> 3.) Only have String/String in our API and just define standard format >> Strings for DateFormatter, NumberFormatter, etc in interfaces or helper >> classes. >> >> 4.) Have the fully typed API. Means we don't only have a > getValue(keyName) >> but also a getDate(keyName), etc >> 5.) Stay String/String in our API (same like 2) but add additional >> Formatter helpers on top of it. >> >> >> I personally like 3 and 5. The main reason is that we are most probably >> not able to define all formats here. Thus any typed API we do define would >> be limited by nature. >> >> There is one major bullet which we should address/take care of: take care >> of timezones and locales. We should really think about those if we define >> the formats. >> >> >> There is also a bit of brain to put into array representations. But lets >> do that later in a separate discussion. >> >> >> LieGrue, >> strub >> >
