Re: [infinispan-dev] RemoteCache vs BasicCache

+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(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev