bytekey
bytekey copied to clipboard
danburkert
Re-write `bytekey` to use `serde` and work on stable rust.
Hi @danburkert, sorry about the delay! The switch took a little longer
than expected and it's been long enough since I've implemented
a serde (De)Serializer pair that a lot had changed :) Would
be great to get your thoughts on this next time you get a chance!
serde
Support for the deprecated rustc-serialize crate has been dropped in
favour of using serde. Serialization has been
implemented by following the guide and conventions described on the
official serde site.
For the most part, the Serializer and Deserializer types behave the
same as their Encoder and Decoder predecessors. Further support has
been added for the serialization of sequences. The end of a sequence is
determined as the byte before the Deserializer's reader produces an
EOF. Thus, deserialization of a sequence with an unknown size requires
that the sequence is at the "end" of the type or is the only element
within the type.
The encoder and decoder modules have been renamed to ser and de
as per the serde convention.
Stable
Unstable features have been removed in favour of using stable APIs.
The deprecated std::io::Chars iterator has been removed in favour of
the utf-8 crate's Utf8ByteEncoder as recommended on the
std::io::Chars tracking issue.
The use of quickcheck has been removed in favour of similarly behaving
random functions implemented in the test modules. The test modules have
been moved to a tests/ subdirectory.
Other notes
While the Serializer and Deserializer still provide
{de}serialize_var_{u64/i64} methods respectively, the usize and
isize serialization processes no longer use them. This has been done
in order to avoid conflating the role of bytekey as an order-preserving
serialization crate with the role of a compression/byte-packing crate.
Perhaps in a future PR we could add a Config option like bincode
does to allow
configuration of behaviour like this?
I just simplified the .travis.yml a little so that it no longer attempts to build on nightly and upload docs. docs.rs has become prevalent enough at this point where it should be fine to use as a recommended documentation link.
@danburkert second on the ping! There's already a fork with a _fix appended, but it would be nicer if this repo was updated. If you don't want to maintain this no longer, I think there will be some who'd like to help out!
