incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: DM modularization
Date Wed, 15 Feb 2012 11:58:56 GMT
Hola Raf!

couldn't Guava - which we are already depending by - replace the
lambdaj option? Not that I have anything against lambdaj, my purpose
purpose is having the minimal dependency set as possible for the
core...

WDYT? TIA,
-Simo

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



On Wed, Feb 15, 2012 at 10:13 AM, Raffaele P. Guidi
<raffaele.p.guidi@gmail.com> wrote:
> Well josql could be replaced by lambdaj - with exactly the same problems at
> all levels but more fanciness - or by plain for loops and if statements.
> This can be the best option if requirements for eviction are clear and not
> changing too often.
>
> Ciao,
>    R
> Il giorno 15/feb/2012 08:51, "Simone Tripodi" <simonetripodi@apache.org> ha
> scritto:
>
>> Hello!
>>
>> I don't have a strong idea ATM how to replace the Josql, if you
>> already have some hints I would be glad to do the legwork :)
>>
>> We're on the same boat, I thought on keeping the default Java
>> serializer as well in the core module - as a second step, we could
>> even think in a ServiceProvider based factory (find between services,
>> use the default if no one has been found)
>>
>> +1 to Olivier's idea - I see the REST layer as an external module on
>> top of the core... did you think about the same or had a different
>> vision?
>>
>> Have a nice day, all the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Wed, Feb 15, 2012 at 8:23 AM, Raffaele P. Guidi
>> <raffaele.p.guidi@gmail.com> wrote:
>> > regarding the formatting thing - I honestly don't remember why I did the
>> > choice, di as you think best. Josql is used at the core level to select
>> > items to purge in the background, I already pointed out it can also be a
>> > performance bottleneck but it was easy to correct with ad-hoc code.
>> > Regarding serializers - yes it should be done but I suggest to keep the
>> > default one in the core. The java serializer is a bit too slow to be the
>> > default one, IMHO. All other ideas and news are great, including the
>> > memcached protocol, which I already investigated long ago (there's a java
>> > me cached server with pluggable implementations somewhere in google code
>> > that is a good starting point) and the fact that you'll be able to
>> leverage
>> > DM in some ways.
>> >
>> > Ciao,
>> >    R
>> > Il giorno 14/feb/2012 22:29, "Simone Tripodi" <simonetripodi@apache.org>
>> ha
>> > scritto:
>> >
>> >> 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/
>> >>
>>

Mime
View raw message