A nice idea! Yes, there could be something in there, even though I thinkbthatbplin java is the best option Il giorno 15/feb/2012 12:59, "Simone Tripodi" <[email protected]> ha scritto:
> 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 > <[email protected]> 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" <[email protected]> > 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 > >> <[email protected]> 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" < > [email protected]> > >> 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/ > >> >> > >> >
