On 9 Jul 2013, at 13:15, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 8 July 2013 20:37, Mircea Markus <mmarkus(a)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.
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)