Denis,
>From client perspective any compute task is also request - response. This
doesn't distinguish compute from any other API anyhow. There are no problem
to add closures, tasks, services, etc.. What is really difficult is
components requiring non-trivial thread interaction and complex request
workflows. E.g. streaming, COPY command, continuous queries, events.
On Thu, Mar 15, 2018 at 10:25 PM, Denis Magda <dma...@apache.org> wrote:
> Pavel,
>
> I just don't see a substantial reason why we need to support the
> compute APIs.
>
> As you properly mentioned, it's not easy to copy all the APIs and, again,
> for what. It's right that the thin client allows decoupling .NET from JVM,
> but its implementation won't be more performant than the regular client's
> one.
>
> So, personally, a thin client (.NET, Node.JS, Java, Python, etc.) is a
> lightweight connection to the cluster that supports classic client-server
> request-response operations. If someone needs more (compute, services,
> streaming, ML), then go for the regular client which is battle-tested and
> available for usage.
>
> --
> Denis
>
>
>
> On Wed, Mar 14, 2018 at 1:33 PM, Pavel Tupitsyn <ptupit...@apache.org>
> wrote:
>
> > Hi Denis,
> >
> > > There are no any plans for that level of support
> > Why do you think so?
> > We already have ScanQuery with filter in .NET Thin Client, which involves
> > remote code execution on server nodes.
> > It is quite similar to Compute.Broadcast and such.
> >
> > Thanks,
> > Pavel
> >
> >
> > On Wed, Mar 14, 2018 at 11:32 PM, Denis Magda <dma...@apache.org> wrote:
> >
> > > Raymond,
> > >
> > > Then I would suggest you keep using the regular .NET client that
> supports
> > > and optimized for computations. Is there any reason why you can't use
> the
> > > regular one?
> > >
> > > --
> > > Denis
> > >
> > > On Wed, Mar 14, 2018 at 12:53 PM, Raymond Wilson <
> > > raymond_wil...@trimble.com
> > > > wrote:
> > >
> > > > Hi Denis,
> > > >
> > > > We are using Ignite.Net and are planning to use 2.4 + .Net Core +
> thin
> > > > client support to enable lightweight containerisable services that
> > > interact
> > > > with the main Ignite compute grid.
> > > >
> > > > These work flows are less about Get/Put style semantics, and more
> about
> > > > using grid compute.
> > > >
> > > > Eg: Here's an example where a client context asks a remote context to
> > > > render
> > > > a bitmap tile in an ICompute:
> > > >
> > > > public Bitmap Execute(TileRenderRequestArgument arg)
> > > > {
> > > > IComputeFunc<TileRenderRequestArgument, Bitmap> func =
> new
> > > > TileRenderRequestComputeFunc();
> > > >
> > > > return
> > > > _ignite.GetCluster().ForRemotes().GetCompute().Apply(func, arg);
> > > > }
> > > >
> > > > In this example, the calling context here could be a lightweight
> > Kestrel
> > > > web
> > > > service end point delegating rendering to a remote service.
> > > >
> > > > Thanks,
> > > > Raymond.
> > > >
> > > > -----Original Message-----
> > > > From: Denis Magda [mailto:dma...@apache.org]
> > > > Sent: Thursday, March 15, 2018 8:31 AM
> > > > To: dev@ignite.apache.org
> > > > Subject: Re: Timeline for support of compute functions by thin
> clients
> > > >
> > > > Hi Raymond,
> > > >
> > > > There are no any plans for that level of support. The thin clients
> are
> > > > targeted for classic client-server processing use cases when a client
> > > > request data from a server, does something with it locally and
> > > potentially
> > > > writes changes back to the server. ICache, SQL fall under this
> > category.
> > > >
> > > > Are you intended to use .NET thin client or anyone else?
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Wed, Mar 14, 2018 at 12:25 PM, Raymond Wilson <
> > > > raymond_wil...@trimble.com
> > > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > >
> > > > >
> > > > > The thin client implementation in Ignite 2.4 only covers a subset
> of
> > > > > the ICache interface.
> > > > >
> > > > >
> > > > >
> > > > > When will we see thin client support for compute, messaging etc?
> > > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Raymond.
> > > > >
> > > >
> > >
> >
>
