Mailing-List: contact directmemory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: directmemory-dev@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAAqLGLPyCBSHho2_VLYK_x27+vdeRibmGjC2jVnwO7AjY5kzDw@mail.gmail.com>
References: 
 <CAAqLGLNnW+RKyqrxYRVz8kAPmEnCWgV=Wej+bbh7Sb1J244otw@mail.gmail.com>
 <CAGnSx04fh7dboJirPUvsenCz4-Hw53GCFC=UXBuQ_7Ts-kXneg@mail.gmail.com>
 <CAAqLGLPyCBSHho2_VLYK_x27+vdeRibmGjC2jVnwO7AjY5kzDw@mail.gmail.com>
From: Olivier Lamy <olamy@apache.org>
Date: Wed, 15 Feb 2012 00:10:21 +0100
Message-ID: 
 <CAPoyBqQxz6r8gw94QjaTBGg4O_5LnxcWARhqo72u+ri4Qj9Nww@mail.gmail.com>
Subject: Re: DM modularization
To: directmemory-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1

One idea I have in mind is to have a kind of DM server "=E0 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 u=
i)

WDYT ?

2012/2/14 Simone Tripodi <simonetripodi@apache.org>:
> Hola Tommy,
>
> yup, there are other topics I would like we work on it, even if not
> strictly related to modularization:
>
> =A0* as you mentioned, Cache has to suport <K, V> generics;
>
> =A0* the cache interface should adhere some "standard" (JCache JSR?)
>
> =A0* supporting namespaces
>
> =A0* 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
> <tommaso.teofili@gmail.com> 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 <simonetripodi@apache.org>
>>
>>> 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:
>>>
>>> =A0* 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/...
>>>
>>> =A0* 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/
>>>


--=20
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy