[infinispan-dev] RemoteCache vs BasicCache

[Mircea Markus]

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

> Indeed that's an excellent idea. But I would add also a common parent
> interface having the basic functionality common to all.

If ConcurrentMap doesn't have what we need, of course :-)

> 
> On 9 July 2013 11:39, Mircea Markus <mmarkus at redhat.com> wrote:
>> 
>> 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)
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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