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
