On Thu, Apr 20, 2017 at 5:06 PM, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 20/04/2017 15:34, Dan Berindei wrote:
>>
>> How big is the DSL API surface (which will be brought into commons)?
>
>
> -1 from me to add anything in commons, I don't think allowing the
> users to query both embedded caches and remote caches with the same
> code is that important. I'd rather go the opposite way and remove the
> BasicCache interface completely.
Actually, we've had requests for interchangeable APIs...
So, according to your strategy we either have each feature implemented with
a divergent specific embedded or remote API, or each feature has its own
feature-api with two separate feature-embedded and feature-remote
implementations. Both plans sound terrible.
Would a divergent embedded vs remote API be that bad? If the
functionality really is different, then I'd rather have different APIs
then force 2 different things use the same API.
E.g. with BasicCache, IMO it would have been better to focus on the
versioned conditional write operations, and remove all the
non-versioned conditional write operations from RemoteCache. I'm sure
we could have improved the versioned API a lot, but instead we worked
mainly on the non-versioned API that we got from BasicCache.
Alternatively, we could go with an infinispan-api package (which Paul
has
been advocating for a long time) which would contain the various interfaces.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat