Re: [infinispan-dev] RemoteCache vs BasicCache

On 9 Jul 2013, at 13:47, Sanne Grinovero <sanne(a)infinispan.org&gt; 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(a)redhat.com&gt; wrote: >> >> On 9 Jul 2013, at 13:15, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: >> >>> On 8 July 2013 20:37, Mircea Markus <mmarkus(a)redhat.com&gt; 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(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 Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev