Define a framing protocol

[utaal]

(from a chat with @frankmcsherry:)

This should allow writing to files and sockets, while accomodating multiple use cases (possibly with different framing structures).

Perhaps Abomonation should have read and write methods for readers and writers, and it does the framing for you and doesn't give the choice of forgetting.

Things to keep in mind:

• If each abomonated object is prepended by a length marker: "the length is also handy in that it lets you zip through an array faster (moving from object to object, rather than deserializing each to determine the length).

A Framed struct:

A struct Framed<T: Abomonation> { len: usize, data: T } which then implements Abomonation, but in a magical special way where maybe (i) len is written as part of abomonation, or maybe (ii) len is computed by fake serialization (relatively cheap, without traversing all the data). This has other advantages, like allocating enough memory to write T rather than repeatedly growing / copying the Vec

• More complex headers may be folded into the abomonated T? For example, what should we do with the message headers in timely_communication?

[frankmcsherry]

A quick comment before I forget: Rust makes no promises about field order, without various repr decorators. This makes the Framed struct less obviously wonderful, as opposed having a distinct usize that we manually force into the stream.

Anyhow, something to be careful about!

[frankmcsherry]

Another thought, the size field has the potential to interfere with memcpy-ability of value types, if that is a concern. For example, if we want to stash a sequence of u64 data, a framing protocol would disrupt this substantially (and inflate the format).

The only point here is that this should probably be "optional" somehow, perhaps driven by the user, or perhaps by having types implement a "has dynamic size" trait or method or something (would be false for value types and their compositions, and become true as soon as you have dynamically sized memory).