Hola Tommy,

yup, there are other topics I would like we work on it, even if not
strictly related to modularization:

 * as you mentioned, Cache has to suport <K, V> generics;

 * the cache interface should adhere some "standard" (JCache JSR?)

 * supporting namespaces

 * Memcached protocol

If we were paid for it, we would have had work for at least 2 years! :)

thanks for the feedback, all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Tue, Feb 14, 2012 at 10:34 PM, Tommaso Teofili
<[email protected]> wrote:
> Wow Simo!
> Outstanding proposals, I'm just +1 on each of them :-)
> I especially like the abstracting serializers thing.
> Also I'd like to put back on track the discussion about Cache<K,V> issue
> since IMHO that would allow much more adoption.
> My 2 cents,
> Tommaso
>
> 2012/2/14 Simone Tripodi <[email protected]>
>
>> Hi all guys,
>>
>> I've finally got the chance - because I also have the need - to do
>> some serious work on DM - now setting up the environment, experiencing
>> the following issues and also got following considerations (some of
>> them already afforded but discussions where to nowhere):
>>
>> disclaimer: I am not an OSGi guru, but I've been a modularization
>> advocate time before OSGi got popularity, so I would like to apply the
>> same approach as well:
>>
>>  * serializers: all serializers are included by default, I am
>> convinced that protostuff serializer can could be extracted as a
>> separated module and maybe among other 3rd parties serializers, such
>> as Kryo <http://code.google.com/p/kryo/>, ASF Thrift
>> <http://thrift.apache.org/> and Avro <http://avro.apache.org/>, and
>> the newer Message Pack <http://msgpack.org/> - users could plug their
>> preferred serializer depending on their taste/needs/...
>>
>>  * net.sf.josql:gentlyweb-utils:1.5 artifact not found - I did a
>> little research and found it on <http://josql.sourceforge.net/> -
>> while the feature of having an embedded query language is really cool,
>> IMHO it could be part of an auxiliary module. I mean, basic query
>> system must be supported by combining objects (and fluent APIs could
>> help) but I'm not fully convinced on having it as foundation of our
>> core module...
>>
>> A side question for Raf: I am not aware about performances, but why
>> did you prefer j.u.Formatter.format( messagePattern, Object... args
>> ).toString() over String.format( messagePattern, Object... args ) ?
>> I extensively used the j.u.Formatter in Commons-Digester3 but for
>> chaining more than one format in the same message, but I didn't notice
>> the benefit of using it for single shot... TIA!
>>
>> As you can see, my proposal is having a minimal DM core, with less
>> dependencies as possible, that can be easily enriched with aux
>> modules...
>>
>> please provide your feedbacks, I have some time/energy to put on DM
>> and glad to do it!
>> TIA,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>

Reply via email to