casey/intermodal

data: Tracking issue

casey opened this issue · 1 comments

casey commented

Tracking issue for the initial implementation of the data crate.

  • structs
  • strings
  • tables
  • enums
  • arrays
  • tuples
  • slices
  • bool, char, u8, u16, u32, u64, u128, i8, i16, i32, i64, i128, usize, isize
  • ()
  • Option
  • Result
  • Cell, RefCell, Arc, Rc, Mutex, Atomic? These things have no meaning in transport, but might be useful in consumer code.
  • CStr
  • Path
  • Fuzz Testing

Misc

  • Should I bother with alignment and padding? Data is always accessed via offset, not pointer, so I can always avoid direct pointer reads. Respecting alignment means I can eventually switch to direct (and unsafe) pointer reads, but will anyone notice the performance improvement?

  • Should length and offset type depend on the size of the message? Would require computing the size of the message, less lengths and offsets, plus the number of lengths and offsets. If the message is less than 256 bytes, lengths and offsets can be u8, less than 65k, u16, etc. Whether or not this is worth it depends on the cost of the extra traversal, and how annoying it makes the API.

  • File identifier and length in every buffer?

  • Read about the cap'n'proto format.

casey commented

Moving to casey/data