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 <boa...@gmail.com> wrote: > How about the JCache API? JSR 107 that is. > > > On 4 July 2014 11:07, Ugo Landini <ugo.land...@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 <hekon...@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 <boa...@gmail.com> -- Claus Ibsen ----------------- Red Hat, Inc. Email: cib...@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/
