[infinispan-dev] RemoteCache vs BasicCache
Galder Zamarreño
galder at redhat.com
Fri Jul 5 01:40:34 EDT 2013
I like #3. As mentioned, it'd be interesting to see some quick examples to get a feel of user code would look.
On Jul 4, 2013, at 2:27 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
> +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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
More information about the infinispan-dev
mailing list