Github user phrocker commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/74#discussion_r110003365
--- Diff: libminifi/src/Site2SiteClientProtocol.cpp ---
@@ -1240,6 +1257,88 @@ void Site2SiteClientProtocol::transferFlowFiles(
return;
}
+void Site2SiteClientProtocol::transferBytes(core::ProcessContext *context,
core::ProcessSession *session, uint8_t *payload, int length,
--- End diff --
I can see the confusion. I was referring to a desire to minimize pointer
usage and more strongly type functions within a public access.
This we are trying to avoid:
*Having arbitrarily large sized arrays. payload comes in with a ptr and
length comes in as a value well above what the NiFi instance could support.
*What happens to NiFI if length is accidentally negative? You convert a
-1 to uint64_t meaning that we would attempt to send a value well outside of
our process control.
* You have a conditional in send in transferBytes, both of which are
public. what would happen if someone uses the protocol to call send instead of
transferBytes with a payload and non null flowFile? The payload would be
ignored. This is not ideal since send/transferbytes are don't differentiate
each other very well.
What inherent need is there to have a generic function that has few
safeguards? Further, this function was intended to be used for sending strings.
Why not use std::string instead of uint8t*,int ? your calls write the size with
length without any checks, whereas the usage of std::vector OR std::string make
this unnecessary and allow us to be more defensive.
Why aren't you using writeUTF ? Do you have the link to the respective java
code for the serialization?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
