[infinispan-dev] RemoteCache vs BasicCache

[Sanne Grinovero]

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.

Sanne

>
> 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)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev