t;
>>> I propose that we consider also the type of connectivity to be supported
>>> in the Flink API Gateway. I would propose to support a couple of calls
>>> option to ingest also events. I am thinking of:
>>> - callback mechanism
>>> - REST
>>>
to be supported
>> in the Flink API Gateway. I would propose to support a couple of calls
>> option to ingest also events. I am thinking of:
>> - callback mechanism
>> - REST
>> - RPC
>>
>>
>>
>>
>> -Original Message-
>> From
pose to support a couple of calls
> option to ingest also events. I am thinking of:
> - callback mechanism
> - REST
> - RPC
>
>
>
>
> -Original Message-
> From: Chen Qin [mailto:qinnc...@gmail.com]
> Sent: Wednesday, March 15, 2017 7:31 PM
> To: dev@fli
...@gmail.com]
Sent: Wednesday, March 15, 2017 7:31 PM
To: dev@flink.apache.org
Subject: Re: Flink as a Service (FaaS)
Hi jinkui,
I haven't go down to that deep yet. Sounds like you have better idea what needs
to be in place.
Can you try to come up with a doc and may be draw some diagram so w
Hi jinkui,
I haven't go down to that deep yet. Sounds like you have better idea what
needs to be in place.
Can you try to come up with a doc and may be draw some diagram so we can
discuss from there?
My original intention is to discuss general function gap of running lots of
micro services(like t
Hi, Chen Qin
We also met your end-to-end use case. A RPC Source and Sink such as netty
source sink can fit such requirements. I’ve submit a natty module in
bahir-flink project which only a demo.
If use connector source instead of Kafka, how do we make the data
persistent? One choice is distributed
