[infinispan-dev] RemoteCache vs BasicCache

Mircea Markus mmarkus at redhat.com
Tue Jul 9 06:39:23 EDT 2013


On 9 Jul 2013, at 13:15, Sanne Grinovero <sanne at infinispan.org> wrote:

> On 8 July 2013 20:37, Mircea Markus <mmarkus at redhat.com> wrote:
>> 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.
> 
> Right that has been confusing, but now we also have evidence of people
> specifically demanding to have the same query functionality (same =
> exact same API) in remote as in embedded.
> 
> Yes we have different functionality, but also there is a good value in
> being able to easily switch a client from embedded vs remote .. what
> about we maintain two different interfaces but having a shared parent?
> 
> We would then try to define as much as possible in the common Cache
> interface, and regularly promote features from the lower interfaces to
> the upper ones when the functionality is covered by both.
> 
> In terms of practical development it's self-evident that we'll always
> be a step ahead in embedded mode, so we should design for it rather
> than trying to prevent it.

That would work but I think it would be nicer to have separate interfaces to define the functionality, as suggested by Tristan:

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)







More information about the infinispan-dev mailing list