I do agree with your proposition, but the idea of an interface being
exposed through documentation seems a bit clunky to me.
On Mon, Apr 5, 2021 at 12:40 PM Alex Plehanov wrote:
>
> Hi Atri,
>
> The new interface is only needed for thin client, it's not a good idea to
> add such a method to
Hi Atri,
The new interface is only needed for thin client, it's not a good idea to
add such a method to thick client too.
пн, 5 апр. 2021 г. в 09:48, Atri Sharma :
> Hi Alex,
>
> Sorry for the late reply.
>
> Regarding the thick client, would it be a challenge to add a new method
> which takes
Hi Alex,
Sorry for the late reply.
Regarding the thick client, would it be a challenge to add a new method
which takes takes interface as parameter? That will not break the back
compatible
On Fri, 2 Apr 2021, 14:32 Alex Plehanov, wrote:
> Hello, Atri
>
> 1. ClientChannelDisconnectListener is
Pavel,
Ok, I agree.
пт, 2 апр. 2021 г. в 18:47, Pavel Tupitsyn :
> Alex,
>
> 1. Agree to deal with CacheEntryEvent as explained
> 2. ClientChannelDisconnectListener - can we have an overload with a
> parameter of this type?
>
> ClientCache#query(ContinuousQuery) - compatible with Thick API
>
Alex,
1. Agree to deal with CacheEntryEvent as explained
2. ClientChannelDisconnectListener - can we have an overload with a
parameter of this type?
ClientCache#query(ContinuousQuery) - compatible with Thick API
ClientCache#query(ContinuousQuery, ClientChannelDisconnectListener) -
specific to
Hello, Atri
1. ClientChannelDisconnectListener is thin client specific.
2. Thick client API uses JCache interfaces, which cannot be modified.
2. We can't modify thick client public API either, due to backward
compatibility.
пт, 2 апр. 2021 г. в 11:51, Atri Sharma :
> Personally, I would
Personally, I would disagree with an interface implementation being
dictated by the documentation rather than the method signature.
How about having a generic interface (placeholder interface), have
both the thick and thin clients expose methods using the interface as
parameters, then let