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

added proposal of optional list-like representation

Hiroyasu Nishiyama 2017-07-20 12:15:41 +09:00
parent 321a9a1f4b
commit ac64165c18
1 changed files with 15 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Design:-msg.parts---description-of-usage.md

@ -31,4 +31,18 @@ Having popped any pushed msg.parts.parts back up to msg.parts the completed `msg
What the current behaviour allows is that the join can be manipulated by changing msg.parts.count (or msg.complete) on any of the intermediate parts. For example the join can be ended early by saying it is now complete - or extra items inserted by just adding to the the count so the existing join doesn't complete.
However - while this makes sense for strings and objects - may need some thinking about for consequences for arrays as currently we try to preserve order in the array. So what does removing or inserting mean in this context - or rather what should the behaviour actually be.
### Proposal: optional list-like representation
The `msg.parts` is adequate tool for doing list-like operations with a Node-RED flow. For example, filtering messages in a message stream or inserting messages to a message stream is useful for handling messages with some relation. However, changing message counts of a message stream needs sotring whole messages in the stream then changing `msg.parts.count` and `msg.parts.index`. For short streams, this should never be a problem. However, for long streams keeping and changing all messages in a message stream may raise problems such as increased memory usage or delay in messages.
So as a optional representation of `msg.parts`,
we propose following linked list representation:
name | type | mandatory | description
------------ | ------------- | ------------ | ------------
next | string | yes | `msg.id` of next message
Either `parts.count` and `parts.index`, or `parts.next` can be used at the same time.
Insertion or deletion of messages with list-like representation can be implemented by keeping smaller number of messages.
Selection of old array-like representation or list-like representation should be selected by producer nodes. Conversion nodes betwee two prepresentations considered to be useful.