Accept and return trailing bytes

[michielbdejong]

Companion to interledgerjs/ilp-connector#405

[emschwartz]

Minor point but I would call this field extensions rather than trailingBytes.

If we don't want to have the extra 0 byte at the end when there are no extensions, then this would be written straight into the buffer rather than being written as a var octet string

[michielbdejong]

Hm, I think that would be confusing, because the term 'extensions' has a specific meaning in OER, namely the thing where you do add the extra 0 byte at the end.

I think we should expose both extensions (for those packet types that have them) and trailingBytes (for all packet types).

[emschwartz]

I don't think it matters that much what it's called in OER because very few people know OER and, however it's implemented for each packet, what the extra bytes are trying to accomplish is the same.

[michielbdejong]

I see your point that we could provide just "a way to add fields" in this module's interface, and abstract the actual OER-level implementation away from view. That would mean we could merge this issue with #31.

But I think at some point, someone who does understand OER will want to use this module, and then this layer of magic, by which the same thing sometimes leads to extensions, and sometimes to trailing bytes, would just be annoying and not at all helpful?

In the end, this module does just two things: write OER packets, and read them. :) So surely, if you want to add extensions, it would be confusing (and actually incorrect), if instead it added trailing bytes, and vice versa?

Or maybe the easiest way to resolve this issue is to stop supporting packet types 1-11 and only support packet types 12-14, then we know the mechanism will always be trailing bytes, and never OER extensions. :)

[emschwartz]

This module isn't for writing oer packets in general, it's for ILP packets. The way the extensions are handled in new packets happens to avoid needing an extra byte to indicate there are none. Note the actual methods this module exposes are very ILP-packet specific, for example they all use the wrapper that includes the type even though they don't explicitly say that's what they're doing.

[michielbdejong]

ok! so then for packet types 12-14 we can support reading and writing trailing bytes inside the envelope as a raw buffer, but we'll just call the field extensions.