You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directmemory.apache.org by Simone Tripodi <si...@apache.org> on 2012/02/14 22:28:36 UTC
DM modularization
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/
Re: DM modularization
Posted by Maurizio Cucchiara <mc...@apache.org>.
Hi guys,
needless to say I agree with everything you said.
> Also I'd like to put back on track the discussion about Cache<K,V> issue
> since IMHO that would allow much more adoption.
Regarding generics, I encountered some problems with the retrieve method
(as I explained here [1])
[1] http://goo.gl/kb1nS
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin :http://www.linkedin.com/in/mauriziocucchiara
Maurizio Cucchiara
On 14 February 2012 22:34, Tommaso Teofili <to...@gmail.com>wrote:
>
>
Re: DM modularization
Posted by Simone Tripodi <si...@apache.org>.
Hola Mau,
Yes that is not so nice, I would take in consideration as a "nice to
have" in a second time.
How does it sound?
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Feb 15, 2012 at 9:36 AM, Maurizio Cucchiara
<mc...@apache.org> wrote:
>> the cache interface should adhere some "standard" (JCache JSR?)
>
> ATM JCache is a kind of work in progress [1], but I agree that is a
> good starting point.
>
> [1] http://groups.google.com/group/jsr107?pli=1
>
> Twitter :http://www.twitter.com/m_cucchiara
> G+ :https://plus.google.com/107903711540963855921
> Linkedin :http://www.linkedin.com/in/mauriziocucchiara
>
> Maurizio Cucchiara
Re: DM modularization
Posted by Maurizio Cucchiara <mc...@apache.org>.
> the cache interface should adhere some "standard" (JCache JSR?)
ATM JCache is a kind of work in progress [1], but I agree that is a
good starting point.
[1] http://groups.google.com/group/jsr107?pli=1
Twitter :http://www.twitter.com/m_cucchiara
G+ :https://plus.google.com/107903711540963855921
Linkedin :http://www.linkedin.com/in/mauriziocucchiara
Maurizio Cucchiara
Re: DM modularization
Posted by Olivier Lamy <ol...@apache.org>.
+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 <si...@apache.org>:
> 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
> <to...@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 <si...@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:
>>>
>>> * 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
Re: DM modularization
Posted by Simone Tripodi <si...@apache.org>.
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
<to...@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 <si...@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:
>>
>> * 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/
>>
Re: DM modularization
Posted by Tommaso Teofili <to...@gmail.com>.
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 <si...@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:
>
> * 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/
>
Re: DM modularization
Posted by "Raffaele P. Guidi" <ra...@gmail.com>.
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" <si...@apache.org> 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
> <ra...@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" <si...@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
> >> <ra...@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/
> >> >>
> >>
>
Re: DM modularization
Posted by Simone Tripodi <si...@apache.org>.
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
<ra...@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" <si...@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
>> <ra...@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" <si...@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/
>> >>
>>
Re: DM modularization
Posted by "Raffaele P. Guidi" <ra...@gmail.com>.
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" <si...@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
> <ra...@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" <si...@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/
> >>
>
Re: DM modularization
Posted by Simone Tripodi <si...@apache.org>.
Salut!
> BTW the goal is to add modules with server impl (war package and maybe
> a distro with embeded tomcat) and a client module.
g r e a t ! +1! :)
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Feb 15, 2012 at 9:33 AM, Olivier Lamy <ol...@apache.org> wrote:
> Hello,
>
>
>
> 2012/2/15 Simone Tripodi <si...@apache.org>:
>> 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
>> <ra...@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" <si...@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/
>>>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: DM modularization
Posted by Olivier Lamy <ol...@apache.org>.
Hello,
As Simone will probably change a lot I will probably wait a bit :-).
BTW the goal is to add modules with server impl (war package and maybe
a distro with embeded tomcat) and a client module.
2012/2/15 Simone Tripodi <si...@apache.org>:
> 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
> <ra...@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" <si...@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/
>>>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: DM modularization
Posted by Simone Tripodi <si...@apache.org>.
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
<ra...@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" <si...@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/
>>
Re: DM modularization
Posted by "Raffaele P. Guidi" <ra...@gmail.com>.
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" <si...@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/
>