This is about how to handle multiple inputs.
I've red a few of the discussions about it and I agree with a lot of the points
the core engine should do little or nothing to solve the multiple input problem (too many different behaviours)
as long as messages are tagged (topic), one can use a function with context to decide what to do
not all nodes allow to specify a topic (http request), in which case one needs to add a change node
should the tagging be done at the origin or at the function input?
I was thinking how to achieve the above in a situation where I do not want / can change the topics or if this is very manual to do. In the end this is not very visible in the flow anyway.
A very lightweight solution could be that any node can declare multiple inputs and the only thing the runtime does is to tag them by the port they came from, like a network router.
It would just add: msg.port = i
And the rest of the processing of the node in unchanged.
In the end, why do we need multiple outputs? One could add a few filters and get the output based on the topic. IMO this would create more symmetry between input and output.
I can't see the benefit to this, other than making the base concepts and runtime implementation more complex.
If you just wanted to tag the message per input, you can achieve this even now. Your inputs would have to be wired to different source flows anyway, so you could just use a change node.
On the other hand, multiple outputs do make sense, as it is an important concept for message routing like the switch node. Or think of situations where nodes create different types of messages.
To be honest, one does not need multiple inputs in the same way as multiples output are redundant.
A node outputting different messages could simply tag them differently and, using multiple filters, send each type to the right location.
A minimalistic runtime only needs 1 input and 1 output: nothing more.
I see it more as a matter of how many clicks are necessary to achieve the goal and if there is anything one can easily reuse rather than redo the same set of operations multiple time.
Sure, but with only one output everything happens inside the message. You lose a lot of readability of what a flow does.
If you want to have "less clicks" to achieve your goal, then you could just use a single function node. One of the main advantages that this kind of visual programming enables you to do, is to see the data flow.
You don't have to use topic to tell them apart... quite often msg from different nodes do have some different property you can use... eg maybe the req property from an http node, etc and the mere presence of that property is enough to let your function decide what to do. Or maybe even the type of payload - eg boolean vs string... plenty of ways.
