+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> 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