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
