Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of ugo.landini@gmail.com
 designates 209.85.212.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACmp6koZpKRnLPHeTfCPXk0cDjSG=aEW9ZtuZiX02xpp1LK9pA@mail.gmail.com>
References: <1404479284253-5753363.post@n5.nabble.com>
	<CALhQg-bXa=apyJc7b7JdQgODWHzrUAdLmm9HZW3YVNodYvdqdQ@mail.gmail.com>
	<E13CEC3A-84A9-4620-9E56-F07E8391E46E@gmail.com>
	<CACmp6kochZUZaZzG_Bw=kz1AD7Q+EXPgDhjb4S965_LVcRwXbQ@mail.gmail.com>
	<CAGB5yNmb+kTYgt0HaD_RMrbTO5e7DS6CWkO7nh4s7zp92fsj-Q@mail.gmail.com>
	<CAAis47Xh+SRC7C_K-zdprH_3-r67bt_ADnOunKRCgXkHhboAyw@mail.gmail.com>
	<CAAis47UMhD1H8qrS7QkpxcT7Y_Ho6vQLtACNkypPcjR=NMzKkA@mail.gmail.com>
	<CACmp6koZpKRnLPHeTfCPXk0cDjSG=aEW9ZtuZiX02xpp1LK9pA@mail.gmail.com>
Date: Wed, 9 Jul 2014 17:34:21 +0200
Message-ID: 
 <CAAis47Vua60ebH3vgAPxSvFU1R8by1pP5UO95J7oF-6_Xcv0Qw@mail.gmail.com>
Subject: Re: An idea of new camel-cache endpoint
From: ugol <ugo.landini@gmail.com>
To: "dev@camel.apache.org" <dev@camel.apache.org>
Content-Type: text/plain; charset=UTF-8

We have two options:

1. code directly against JCache (JSR 107)
pro: out of the box integration with JSR 107 compliant cache providers
cons: doesn't work with every provider. JCache API don't cover lot of
use cases (it's temporary in nature for example, while Infinispan is
more on the "grid" side)
2. have a camel cache api (loosely based on JSR 107 / 347)
pro: can cover every use case and can be implemented
cons: integration with cache providers not out of the box

1. is really easy and straightforward, but I don't know if it would be
feature rich enough to "deprecate" more specific components

On Wed, Jul 9, 2014 at 4:55 PM, Matt Sicker <boards@gmail.com> wrote:
> Technically components like camel-jms/camel-sjms, camel-jdbc/camel-sql,
> camel-jpa, camel-jcr, etc., all code to JSRs instead of particular
> implementations. I don't think I've seen an equivalent for camel-camel ;)
>
> Using the JSRs for a generic cache component would be nice because EHCache
> and Infinispan both already support the JCache API, and Hazelcast is
> working on adding support for it. That would make a better candidate for
> the component named "camel-cache" as you could still even use EHCache with
> it!
>
>
> On 9 July 2014 09:47, ugol <ugo.landini@gmail.com> wrote:
>
>> Do we have any example of a generic camel component with different
>> implementations?
>> Or should be camel-cache just a set of common API?
>>
>> On Wed, Jul 9, 2014 at 4:08 PM, ugol <ugo.landini@gmail.com> wrote:
>> >> 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?
>> >
>> > In my idea, it's just that JSR107 and JSR 347 already cover what
>> > caches/grids have in common, so we can use those JSR as an inspiration
>> > for a good design.
>> >
>> >> Okay back to the cache. Sure guys we love contributions and surely I
>> >> would like to see this moving forward.
>> >
>> > I'll see what I can do next weeks
>> >
>> > --
>> > uL
>> >
>> > Pragmatist
>> > http://blog.ugolandini.com
>> > http://www.flickr.com/photos/ugol/
>>
>>
>>
>> --
>> uL
>>
>> Pragmatist
>> http://blog.ugolandini.com
>> http://www.flickr.com/photos/ugol/
>>
>
>
>
> --
> Matt Sicker <boards@gmail.com>


-- 
uL

Pragmatist
http://blog.ugolandini.com
http://www.flickr.com/photos/ugol/