[infinispan-dev] RemoteCache vs BasicCache

[Sanne Grinovero]

+1 for #2 or #3

Having multiple interfaces sounds interesting, as "traits" but I'm not
too convinced.. would need to play with it.
But I definitely think we need at least one common API so that people
can easily replace embedded/remote usage.

If we had a sane roadmap I would say go for #3, and we eventually back
off if it doesn't look too good in examples.

Sanne

On 4 July 2013 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.
>
> Tristan
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev