camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: An idea of new camel-cache endpoint
Date Wed, 09 Jul 2014 13:12:03 GMT
Hi guys

I had the pleasure of meeting Piotr today in London at a fuse community event.

I like the idea of having some common api for caching in Camel. And
making sure that this is the easiest and a good way to use caching.

Altough there is also the jcache spec that Matt talks about. Not sure
where that spec fits into this picture?

Also a problem is that camel-cache was a bad name, as it ought to been
named camel-ehcache. People may by mistake think that camel-cache is
the default and best cache component to use. Where as maybe hazelcast
/ infinispan or some of the others would have been better.

So if camel-cache is that cache api, and then we have different impls
of them such as ehcache, hazelcast etc.

Also the existing components such as hazelcast / infinispan ought to
be still used as today, so they if possible, support dual mode, eg as
today and then in the future that camel-cache api.


As today we have many components around other similar techs, there may
be a need for something similar in the http space, so http client can
be a bit similar to use. eg camel-jetty / camel-http / camel-ahc /
camel-netty-http had some common api as well.

Okay back to the cache. Sure guys we love contributions and surely I
would like to see this moving forward.


On Sun, Jul 6, 2014 at 7:14 AM, Matt Sicker <boards@gmail.com> wrote:
> How about the JCache API? JSR 107 that is.
>
>
> On 4 July 2014 11:07, Ugo Landini <ugo.landini@gmail.com> wrote:
>
>> I am interested. We could implement something similar to JSR 347 to have a
>> reasonably designed API
>>
>> -- uL
>>
>> Pragmatist
>> http://ugolandini.com
>>
>>
>> > On 04/lug/2014, at 15:52, Henryk Konsek <hekonsek@gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > Redirecting discussion [1] to the dev list.
>> >
>> >> Was also speaking with Henryk Konsek about camel-cache deprecation
>> >> His idea is to get camel-cache2 component to be much more generic.
>> >
>> > First of all I propose to rename camel-cache to camel-ehcache. Current
>> > name is too generic IMHO. Also keep ig mind that many folks use
>> > existing camel-cache component, so we should not deprecate it too
>> > eagerly.
>> >
>> > I'd like to have generic camel-cache component (named let's say
>> > camel-cache2 or camel-cache-api) that will provide only map-like
>> > interface for the cache and default in-memory implementation of the
>> > cache based on Camel LRU cache. Then particular components could come
>> > with their implementations of our generic cache interface. For
>> > example:
>> > camel-hazelcast (HazelcastCacheProvider)
>> > camel-guava (MapBuilderCacheProvider)
>> > camel-jgroups (JGroupsSharedStateCacheProvider)
>> > camel-ehcache (EhcacheCacheProvider)
>> > camel-infinispan (InfinispanCacheProvider)
>> > camel-spring (SpringCacheApiCacheProvider)
>> > ...and so forth.
>> >
>> > Cache is something that should be easily pluggable, without modifying
>> > client code. Anybody interesting in participating in creating
>> > something like camel-cache-api?
>> >
>> > Cheers.
>> >
>> > [1]
>> http://camel.465427.n5.nabble.com/An-idea-of-new-camel-cache-endpoint-tp5753363.html
>> >
>> > --
>> > Henryk Konsek
>> > http://henryk-konsek.blogspot.com
>>
>
>
>
> --
> Matt Sicker <boards@gmail.com>



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/

Mime
View raw message