+1 One idea I have in mind is to have a kind of DM server "à la" memcache.
Just some api to do in simile code :-) : * cacheServer.put(cacheRequest) * cacheServer.get(cacheRequest) * cacheServer.remove(key) * etc Bean CacheRequest fields : * key * serializer impl to use * etc.. As it, it will be possible to share cache objects between applications. And the server will expose some rest apis for statistics (with an minimum ui) WDYT ? 2012/2/14 Simone Tripodi <[email protected]>: > 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/ >>> -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy
