[infinispan-dev] RemoteCache vs BasicCache

[Sanne Grinovero]

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

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