ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-15 📝 Original message: Good morning list, An ...
📅 Original date posted:2018-11-15
📝 Original message:
Good morning list,
An item added discussed in the summit was the proposed "type,len,value", which is added to the end of messages and other intercommunication structures (invoices and so on).
This would allow some transition to future additional fields while maintaining backward compatibility.
I believe these were brought up:
1. For a sequence of `type,len,value`, each `type` must be unique. -- accepted.
2. For a sequence of `type,len,value`, the `type`s must be in ascending order -- not explicitly accepted or rejected. It would be easier to check uniqueness (the previous rule we accepted) here for a naive parser (keep track of some "minimum allowed type" that initializes at zero, check current type >= this, update to current type + 1) if `type`s are in ascending order.
Now for bikeshedding:
1, `type` - one byte or two?
2. `type` - maybe some other name, since we already use `type` for messages? How about, `key` instead?
3. `type` - does "it's OK to be odd" apply? i.e. if an even `type` that is not known is found, crash and burn. But intent of this system is for future expansion for optional fields, so...?
4. `len` - measures bytes of `value`, obviously since if the receiver does not know the `type` then it cannot know what unit is used for the `value`.
5. `len` - one byte or two? I believe we tend to use two bytes for various lengths.
6. BOLT - I propose making a separate BOLT for `type,len,value`, which other messages and so on simply refer to.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181115/815ebee9/attachment.html>;
📝 Original message:
Good morning list,
An item added discussed in the summit was the proposed "type,len,value", which is added to the end of messages and other intercommunication structures (invoices and so on).
This would allow some transition to future additional fields while maintaining backward compatibility.
I believe these were brought up:
1. For a sequence of `type,len,value`, each `type` must be unique. -- accepted.
2. For a sequence of `type,len,value`, the `type`s must be in ascending order -- not explicitly accepted or rejected. It would be easier to check uniqueness (the previous rule we accepted) here for a naive parser (keep track of some "minimum allowed type" that initializes at zero, check current type >= this, update to current type + 1) if `type`s are in ascending order.
Now for bikeshedding:
1, `type` - one byte or two?
2. `type` - maybe some other name, since we already use `type` for messages? How about, `key` instead?
3. `type` - does "it's OK to be odd" apply? i.e. if an even `type` that is not known is found, crash and burn. But intent of this system is for future expansion for optional fields, so...?
4. `len` - measures bytes of `value`, obviously since if the receiver does not know the `type` then it cannot know what unit is used for the `value`.
5. `len` - one byte or two? I believe we tend to use two bytes for various lengths.
6. BOLT - I propose making a separate BOLT for `type,len,value`, which other messages and so on simply refer to.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181115/815ebee9/attachment.html>;