frodovdr
/
node-red
mirror of https://github.com/node-red/node-red.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Updated Design: Enhancements to Split Join nodes (markdown)

Dave Conway-Jones 2017-06-05 12:20:37 +01:00
parent 346afd9412
commit 3d912b2bd7
1 changed files with 9 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
Design:-Enhancements-to-Split-Join-nodes.md

@ -6,10 +6,12 @@ The Split can handle Strings, Arrays, or Objects - and returns one msg for each
The Split node takes a single message and (currently) creates multiple messages.
*Note* - currently that is the simple way to think of it... 1 in multiple out...
#### Proposal 1
Add support for Buffers to be split - let the split "target" be able to be specified as an array format - eg ["0x02","0xf2"] sort of thing (that is itself then parsed into a buffer) to use with buffer.indexOf...
*implemented in enhanced split/join branch* - Add ability to split a binary buffer object on a char or another buffer (specified by and array or string as above) - Keeps any remainder left over for next packet to arrive . As a result it can't provide a total number of parts in advance, but can provide a count. Provides a count when there is zero remainder.
### Join Node
@ -49,17 +51,21 @@ In addition if a msg does arrive with a `msg.completed` property - then the accu
### Proposal 1b - Accumulate key/value pairs mode
Similar in to proposal 1, this should also be the equivalent but for the **key/value** mode of operation - ie allow use of a msg property (like the topic) to create the properties - this would be even simpler than Proposal 1a above for use with UI nodes, and general msgs that just have a topic and payload (for example MQTT inputs)
### Potential implementation
### Potential implementation
These could be implemented,
- either as stand alone modes of operation. IE Accumulate objects and Accumulate key/value pairs. (see below)
- or as a sub mode of the exiting modes - for example by allowing a "special" use of a count of zero inputs to indicate "infinite" (ie send every time).
Currently the first of these is implemented in enhanced split/join branch. (IE separate discrete mode of operation)
![](http://g.recordit.co/SQMEE8pJmD.gif)
### Proposal 2
In the **key/value** mode(s) the outgoing msg.topic is currently set by the last to arrive msg. It should be possible to set a new overall msg.topic for the new merged object. (Actually it can be another property that is used as the key - not just topic - but the thinking is the same).
In the **key/value** mode(s) the outgoing msg.topic is currently set by the last to arrive msg. It should be possible to set a new overall msg.topic for the new merged object. (Actually it can be another property that is used as the key - not just topic - but the thinking is the same). *implemented in enhanced split/join branch*
### Proposal 3
Enhance the Join node to have a name field - All nodes should have a name field - not sure why we forgot it here.
Enhance the Join node to have a name field - All nodes should have a name field - not sure why we forgot it here.
*implemented in 0.17 branch - as it was this that exposed the dashboard namespace issue*