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 <plehanov.a...@gmail.com> wrote:
>
> 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 <a...@apache.org>:
>
> > 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, <plehanov.a...@gmail.com> wrote:
> >
> > > 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 <a...@apache.org>:
> > >
> > > > 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 ClientChannelDisconnectListener actually
> > > > implement that interface and override the base methods? The methods
> > > > can be no-op in the thick clients.
> > > >
> > > > On Fri, Apr 2, 2021 at 2:04 PM Alex Plehanov <plehanov.a...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Hello, Igniters!
> > > > >
> > > > > I'd like to discuss java thin client Continuous Queries public API.
> > > > >
> > > > > Currently, the thin client is not JCache compatible and without
> > JCache
> > > > > compatible cache instance we can't use classes and API which already
> > > used
> > > > > by the thick client for cache entry events listening.
> > > > > In my first attempt to implement thin client CQ I've tried to create
> > > own
> > > > CQ
> > > > > classes and interfaces for thin client, but such API looks weird. On
> > > the
> > > > > one hand, we should use CacheEntryEventFilter (JCache interface)
> > since
> > > > it's
> > > > > required by the server-side, on the other hand, we can't use
> > > > > CacheEntryUpdatedListener since it requires CacheEntryEvent which
> > > > requires
> > > > > an instance of Cache (JCache interface), which doesn't exist on the
> > > > > thin-client side.
> > > > > We've already discussed this problem with Pavel Tupitsyn in ticket
> > [1]
> > > > and
> > > > > come to an agreement that the most suitable solution is to implement
> > > some
> > > > > private thin-client cache to JCache adapter, but not expose it to
> > > public
> > > > > API and don't provide full JCache support by the thin client (see
> > > > comments
> > > > > in the ticket for more details). In this case, we can reuse CQ
> > classes
> > > > and
> > > > > interfaces and make the API similar to thick-client.
> > > > >
> > > > > Another problem: for the thin client we should be able to inform the
> > > user
> > > > > about channel failure. I propose to introduce some interface
> > > > > ClientChannelDisconnectListener and notify about channel failure if
> > > > > provided CacheEntryListener implements this interface. Unfortunately,
> > > if
> > > > we
> > > > > want to keep thin client API similar to the thick client we can't
> > > > > explicitly use this interface in methods parameters, so the knowledge
> > > > that
> > > > > user can use this interface for cache entry listener can be obtained
> > > only
> > > > > from JavaDoc or Ignite documentation.
> > > > >
> > > > > Igniters, WDYT?
> > > > >
> > > > > Here is PR with implemented proposals [2].
> > > > >
> > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-14402
> > > > > [2]: https://github.com/apache/ignite/pull/8960
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Atri
> > > > Apache Concerted
> > > >
> > >
> >

-- 
Regards,

Atri
Apache Concerted

Reply via email to