[infinispan-dev] RemoteCache vs BasicCache

[Manik Surtani]

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

> Dear all,
> 
> 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.

I like option 3, especially since there is minimal "cost" to such granularity.  However, I see that a BasicCache interface (that extends QueryableCache, TransactionalCache, AsyncCache) may still be useful so code that uses features from all those interfaces can still be written in a manner than is abstract from the remote/embedded detail.

> 
> Tristan
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid