From ac64165c189671c4b3f593bf8771247bda9696a2 Mon Sep 17 00:00:00 2001
From: Hiroyasu Nishiyama <30289092+HiroyasuNishiyama@users.noreply.github.com>
Date: Thu, 20 Jul 2017 12:15:41 +0900
Subject: [PATCH] added proposal of optional list-like representation

---
 Design:-msg.parts---description-of-usage.md | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/Design:-msg.parts---description-of-usage.md b/Design:-msg.parts---description-of-usage.md
index 1bb7bbf..7bff855 100644
--- a/Design:-msg.parts---description-of-usage.md
+++ b/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.
- 
\ No newline at end of file
+ 
+### 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.
\ No newline at end of file