With Serde 1.0 hot off the presses the Library Team has decided to officially deprecate the rustc-serialize crate. The crate itself has moved to the rust-lang-deprecated organization and the documentation has been updated to reflect the fact that it is now deprecated.
As the fourth most downloaded dependency on crates.io we realize that this may affect quite a few crates! It's highly recommended to migrate to Serde which has a huge number of improvements over rustc-serialize, including (but not limited to):
- Deserializing maps and such where the structure is not known ahead of time
- Zero-copy deserialization
- Insanely fast speed
- Plenty of bugs fixed (especially in the JSON implementation)
- Vastly more flexible and customizable
- A large, enthusiastic, growing community
At this time the library team will no longer be looking to merge and/or fix feature requests in the rustc-serialize crate. We will continue for the time being to merge bug fixes while crates continue to migrate to serde, but it's recommended to move to serde soon!
If you have any questions please feel free to ask here!
What's going to happen with base64/hex coding?
This crate has a different license and has less features than
I can't say about the features but MIT license is more permissive than Apache2, so technically I don't think it is a problem. Correct me if I'm wrong, though.
MIT license requires you to publish copyright information everywhere and does not have any patent protections.
If base64 was patented, we'd know by now.
I think Apache 2 also requires you to include original copyright information with distributed source. In terms of patent protection, you're probably right, but if base64 was patented we would have much bigger problems overall.
Right, but not with the binary though.
This is all besides the point and off-topic.
I didn't intend this topic to become a discussion of various licenses, only to say that the alternative crate I was pointed at is not equivalent to what rustc_serialize currently provides.
data-encoding does also not appear to support MIME encoding/decoding.
From a quick glance, it seems like it might be easy to add as a PR. I'll see if I can whip it up quickly later when I'm in front of my PC.
EDIT: No need for PR. See reply below.
Apologies for double posting.
I hacked together a small example to show how you can do MIME encoding/decoding with
See README at https://github.com/lawliet89/data-encoding-mime for more information.
Will Serde stay independent and not be integrated within the Rust language?
What about compability serde and rustc-serialize? For example I have serialized to json and saved on disk several structures with help of rustc-serialize, it is possible to load them with serde from this file?
I'm not sure if the default serialization format of serde is exactly the same as rustc-serialize. But serde is definitely flexible enough to load data from rustc-serialize.
This is functional but much slower than rustc-serialize's implementation since it copies all data a second time. I was hoping for a response from the libs team but in the mean time I've forked the base64 implementation here: https://crates.io/crates/b64
What kind of response were you looking for in particular? rustc-serialize is not going to disappear - if the base64 stuff in it works for you, you're welcome to continue using there forever, or copy it out to another crate or whatever.
Correct me if I'm wrong, but to me deprecation means that there is an intent to retire rustc-serialize at some point in the future (but not necessarily anytime soon), that it will no longer be maintained, that people will tell you "why are you using rustc-serialize, it's deprecated?", and as a result that you should make every effort to stop using it. It seems to me the decision to deprecate was solely based on the serialization functionality now being superseded by serde, perhaps it was just overlooked that there was other functionality provided by this crate which was not available elsewhere.
I opened an issue for adding Apache2, and MIME support was added 3 days ago. It's also faster than