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

+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

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.

On 4 Jul 2013, at 14:10, Tristan Tarrant <ttarrant(a)redhat.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

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

On 9 Jul 2013, at 20:07, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > On 9 July 2013 18:01, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: >> >> 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 :-) > > ConcurrentMap adds a load of pitfalls which should not be there: all > the methods whose result is depending on the node they are run on. > > I know we make it clear in javadocs and several warnings on the doc, > but experience tells that this is not good enough :-( > > I'd propose to remove them all, and provide an adapter layer > (optional) for those needing to replace a ConcurrentMap in their code. > Methods like "size()" - as discussed before - are possibly useful for > statistics and diagnostics, and therefore should be accessed in a > different explicit way. > > cache.diagnosticsStatistics().localContainerSize() +1. That would be part of the migration towards to JCache API and implemented in 7.0. I think Tristan was looking for something now.

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

On 9 Jul 2013, at 20:22, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: >>> ConcurrentMap adds a load of pitfalls which should not be there: all >>> the methods whose result is depending on the node they are run on. >>> >>> I know we make it clear in javadocs and several warnings on the doc, >>> but experience tells that this is not good enough :-( >>> >>> I'd propose to remove them all, and provide an adapter layer >>> (optional) for those needing to replace a ConcurrentMap in their code. >>> Methods like "size()" - as discussed before - are possibly useful for >>> statistics and diagnostics, and therefore should be accessed in a >>> different explicit way. >>> >>> cache.diagnosticsStatistics().localContainerSize() >> >> +1. That would be part of the migration towards to JCache API and implemented in 7.0. I think Tristan was looking for something now. > > I see. But since we plan a change anyway, why not doing the right > thing right away? That would making Cache not implement the j.u.ConcurrentMap interface but a new interface, potentially the one exposed by JSR 107. Whilst the timing is good (new major) I think that is a rather large change in the context of the already very busy 6.0 and not as important as other features or stability. There's also JDG backward compatibility. I guess Tristan can comment more on the effort needed for implementing such a change.

> Ok we can change interfaces on mayor versions, still > the less you change them the better: any change is a big pain for > other projects. This is not that much a change in method signature but only moving methods around to separate interfaces.

> > Unless Tristan was looking for something backwards compatible right > now? Of course I'd prefer that, I was making suggestions assuming the > interface chain would change now in some non-compabile way. 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