arpadboda commented on code in PR #9182:
URL: https://github.com/apache/nifi/pull/9182#discussion_r1720086806
##########
nifi-api/src/main/java/org/apache/nifi/processor/ProcessContext.java:
##########
@@ -73,6 +73,15 @@ public interface ProcessContext extends PropertyContext,
ClusterContext {
*/
void yield();
+ /**
+ * <p>
+ * An alternative name for the yield() method so that it can be called
from Python.
+ * </p>
+ */
+ default void yieldResources() {
Review Comment:
I agree with the approach of keeping the python API simple, on the other
hand, we are in the perfect time to modify/extend it based on our experience
with it. It's not final in M4, but a very cool thing to have, so people started
using it and naturally hit limitations. Before going GA we have the chance to
adjust it to our needs, later on our hands will be much more tied because of
the compatibility we have to respect.
The "Handling of the contents of the failure result in the python
FlowFileTransform API" thread on the dev mailing list was I think one of the
first occasions where the limits of the current API was hit and people don't
completely agree on the general approach moving forward. From this point most
of the questions become a tradeoff:
-do we want to allow the users to implement python controller services for
eg?
-how much feature-parity we are going to provide with the java api when
creating processors?
-how simple we would like to keep the python api?
-how "intrusive" we let python related code changes to be on the java side?
I feel like we all have different answers to these questions above.
My personal preference is the feature parity way, but I'm pretty sure there
is no consensus on that.
This is way off the scope of this PR, but I think we should find a general
approach and common goals for the python API and make sure these are clear for
everyone and kept in mind before submitting changes, otherwise we will end up
discussing things on PRs that are more like principles and not implementation
details.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
