2011/1/11 Norman Maurer <[email protected]>:
>> + simple persistence: I find that often a mailet needs some sort of
>> simple persistence or some sort of "advanced/dynamic" configuration.
>> a list of domains for a whitelist, a list of usernames (list<string>)
>> a list of email addresses for a mailing list expansion (list<string>)
>> map of aliases (map<string,string>)
>> a properties like configuration (map<string,string>)
>> They are simple list of strings or maps of strings to strings.
>> Why don't we provide a way for mailets to declare they work with a
>> "named map" or a "named list" and automatically provide
>> persistence/lookup methods in a container agnostic way?
>> This way a container could provide a simple file based (properties
>> files works too!) a jdbc/jpa/jcr based implementation (configured in
>> the container not in the mailet).
>> I know this may sound "limited" but mailets could then encode/decode
>> their data in simple strings to be added as values in the map and this
>> would be a very little cost compared to writing the persistence backed
>> (or being limited to a simple file or jdbc solution hardcoded in the
>> mailet itself).
>
> So you think about some kind of key/value store.. right ?
Well, the most basic implementation could simply store
"${name}.properties" file in the configuration folder and read them as
Property objects (Map<String, String>).
So, it is a key value store, but not in the NoSQL version. It doesn't
need to be fast or to be distributed or anything else and also doesn't
need to scale to millions of values.
>From the container it looks like a multimap: a list of named maps, or
simply a map of maps.
This kind of structure is easy enough to be easily implemented for
every backend.
Stefano
