[infinispan-dev] RemoteCache vs BasicCache

[Mircea Markus]

TBH I think having the RemoteCache implementing Cache wasn't such a good idea as it caused confusion through users: e.g. people trying to use transactions with a remote cache. I like the multiple interfaces idea as it clearly indicates what's actually supported in both remote and embedded modes.

On 4 Jul 2013, at 14:10, Tristan Tarrant <ttarrant at redhat.com> wrote:

> during my latest destructive commits, I have liberated 
> infinispan-client-hotrod from infinispan-core.
> One of the things I did was remove the inheritance of RemoteCache from 
> BasicCache, since my argument was that our base API contract was the 
> ConcurrentMap interface and that would suffice, since it implied that a 
> remote Cache could match a core Cache in functionality (which is 
> somewhat true). Now, I'm not convinced it was a good choice after all, 
> since there are indeed a ton of common methods (the async API for one).
> 
> 
> I would like people's opinion on the above, and propose one of the 
> following:
> 
> 1. we leave it as it is
> 2. we move org.infinispan.api to infinispan-commons and make RemoteCache 
> inherit from BasicCache
> 3. we go even further and split the concept of BasicCache into multiple 
> interfaces: AsyncCache, TransactionalCache, QueryableCache, etc and add 
> them to the RemoteCache as we will in the blanks, since we are aiming at 
> feature parity. This could also mix well with the ideal of having the 
> JCache API as our public API.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)