Return-Path: X-Original-To: apmail-incubator-directmemory-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-directmemory-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A6229983C for ; Wed, 15 Feb 2012 09:13:47 +0000 (UTC) Received: (qmail 1916 invoked by uid 500); 15 Feb 2012 09:13:47 -0000 Delivered-To: apmail-incubator-directmemory-dev-archive@incubator.apache.org Received: (qmail 1894 invoked by uid 500); 15 Feb 2012 09:13:47 -0000 Mailing-List: contact directmemory-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: directmemory-dev@incubator.apache.org Delivered-To: mailing list directmemory-dev@incubator.apache.org Received: (qmail 1885 invoked by uid 99); 15 Feb 2012 09:13:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2012 09:13:47 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of raffaele.p.guidi@gmail.com designates 74.125.82.43 as permitted sender) Received: from [74.125.82.43] (HELO mail-ww0-f43.google.com) (74.125.82.43) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2012 09:13:42 +0000 Received: by wgbdr13 with SMTP id dr13so1425483wgb.0 for ; Wed, 15 Feb 2012 01:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6QHSbEMQp+H/0jexhohCtb/Rdjd9pFXd35+0S86GGJY=; b=X4B7sYG44vWbE2HVGNLGsOkLl1tT8G/XZX6PEddL2JFV2Xqr8un+4Qkij61vZx9+qc MDjeS7wiKTOoGIZqBel0V3iQFMt6RfPK6zEVIZD/l1qfrsbPSZhrKsJmmCzDcScNA+gM uNGqUo2k7WSbPOV5WnjT6vpdjA3XmW+Ho4JHU= MIME-Version: 1.0 Received: by 10.180.7.231 with SMTP id m7mr8929887wia.3.1329297200979; Wed, 15 Feb 2012 01:13:20 -0800 (PST) Received: by 10.216.195.146 with HTTP; Wed, 15 Feb 2012 01:13:20 -0800 (PST) Received: by 10.216.195.146 with HTTP; Wed, 15 Feb 2012 01:13:20 -0800 (PST) In-Reply-To: References: Date: Wed, 15 Feb 2012 10:13:20 +0100 Message-ID: Subject: Re: DM modularization From: "Raffaele P. Guidi" To: directmemory-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=90e6ba211f1b771df404b8fd1f91 --90e6ba211f1b771df404b8fd1f91 Content-Type: text/plain; charset=ISO-8859-1 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" 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 > 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" > 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 , ASF Thrift > >> and Avro , and > >> the newer Message Pack - 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 - > >> 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/ > >> > --90e6ba211f1b771df404b8fd1f91--