> 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 <alexpolovt...@gmail.com> 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 <ptupit...@apache.org> > 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 >
