> 1. I think that the "streamData" method has quite a lot of parameters. Can
> we reduce their number by introducing a holder class, for example
> "ReceiverOptions" or "ReceiverConfig"?
I think that's ok. The last 3 parameters are consistent with the Compute
API.
> 2. Can you please elaborate on the "motivation" section a bit? It's very
> brief and it's not clear what use cases you are going to cover.
Added Use Cases section there.
> 3. Why do we need to be able to serialize user data into a "string"? It
> will be converted to a byte array anyway. Can we make the return type of
> the "payloadFunc" more strict? Also, what is this function needed for,
> apart from serialization? If serialization is its main purpose, maybe we
> should reflect that in its type/parameter name?
String is just an example, it can be of any supported type. Yes, byte[]
would be a better choice for serialization.
The function is needed to extract the data to be sent to the server from
the raw incoming data.
> 4. Can you please elaborate on the "deploymentUnits" parameter? Are these
> the units that contain the receiver classes? Can you please reflect that
in
> the documentation?
Those are the same deployment units we have in the Compute API, please see
the "Receiver Deployment" section.
> 5. It would be nice to have an example of a receiver implementation in the
> IEP.
Done
On Thu, May 2, 2024 at 12:08 PM Aleksandr Polovtsev
wrote:
> Hi, Pavel, thanks for the great proposal.
>
> I have the following comments:
>
> 1. I think that the "streamData" method has quite a lot of parameters. Can
> we reduce their number by introducing a holder class, for example
> "ReceiverOptions" or "ReceiverConfig"?
> 2. Can you please elaborate on the "motivation" section a bit? It's very
> brief and it's not clear what use cases you are going to cover.
> 3. Why do we need to be able to serialize user data into a "string"? It
> will be converted to a byte array anyway. Can we make the return type of
> the "payloadFunc" more strict? Also, what is this function needed for,
> apart from serialization? If serialization is its main purpose, maybe we
> should reflect that in its type/parameter name?
> 4. Can you please elaborate on the "deploymentUnits" parameter? Are these
> the units that contain the receiver classes? Can you please reflect that in
> the documentation?
> 5. It would be nice to have an example of a receiver implementation in the
> IEP.
>
> On Thu, May 2, 2024 at 10:59 AM Pavel Tupitsyn
> wrote:
>
> > Igniters,
> >
> > Please review the proposal [1] and let me know what you think
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-121%3A+Data+Streamer+with+Receiver
> >
>
>
> --
> With regards,
> Aleksandr Polovtsev
>
