Val, my preference would be not to have compute functionality on thin clients,
as it would introduce extra security risk.
Any particular reason why you are asking for this feature?
D.
On Apr 2, 2018, 8:47 PM, at 8:47 PM, Valentin Kulichenko
<valentin.kuliche...@gmail.com> wrote:
>Folks,
>
>Any other thoughts on this? Should we create tickets for compute
>support if
>there are no objections?
>
>-Val
>
>On Thu, Mar 22, 2018 at 4:27 PM, Valentin Kulichenko <
>valentin.kuliche...@gmail.com> wrote:
>
>> I agree that compute and services functionality is important for thin
>> client. It doesn't seem to be very hard to implement, but would
>provide
>> much better flexibility, as users would be able to do remote
>invocation of
>> arbitrary code, use collocated processing, etc. Having an ability to
>do
>> this from a thin client without joining the topology is a huge
>advantage.
>>
>> -Val
>>
>> On Fri, Mar 16, 2018 at 4:00 AM, Vladimir Ozerov
><voze...@gridgain.com>
>> wrote:
>>
>>> 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.
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
