@choeger ask the question "Why not use msgpack for transformations". After all, it would not only make the file format more consistent, but it would eliminate the need to parse transformation strings. It would also be well aligned with #43.
Initially, I thought that the strings would be more compact. But in discussing it with Christoph, I recognized that the most common transformation, by far, would be the pure alias transformation: aff(1.0,0.0). Even if you use integers to represent this string, you can still only get it down to aff(1,0) (8 bytes). That seems pretty small. But in discussing it with Christoph, I realized that if we represented this transformation as:
{"k": "aff", s: 1, o: 0}
and then used msgpack to pack it. We get the byte sequence:
\x83\xa1k\xa3aff\xa1s\x01\xa1o\x00
which is only 13 bytes. Yes, we pay 7 bytes per alias signal for using msgpack. But we make implementations easier since people don't have to include transformation parsing.
@choeger ask the question "Why not use msgpack for transformations". After all, it would not only make the file format more consistent, but it would eliminate the need to parse transformation strings. It would also be well aligned with #43.
Initially, I thought that the strings would be more compact. But in discussing it with Christoph, I recognized that the most common transformation, by far, would be the pure alias transformation:
aff(1.0,0.0). Even if you use integers to represent this string, you can still only get it down toaff(1,0)(8 bytes). That seems pretty small. But in discussing it with Christoph, I realized that if we represented this transformation as:and then used
msgpackto pack it. We get the byte sequence:which is only 13 bytes. Yes, we pay 7 bytes per alias signal for using
msgpack. But we make implementations easier since people don't have to include transformation parsing.So I think this is a good idea for version 2!