Consider changing Ipv*Addr serialization to a tuple of integers from a string

[erickt]

Serde is missing support for Ipv4Addr and Ipv6Addr. It would be nice if we supported it and other std::net types. One open question though is how should we actually serialize IP addresses? It would be the most compact by serializing to a u32 or (u64, u64), or in pieces with (u8, u8, u8, u8) and 8 u16s, but I'm sure human consumable formats like markdown or JSON would prefer a textual format.

[oli-obk]

[127, 0, 0, 1] is very human readable imo. As long as it's done with serialize_tuple and serialize_u8 bincode will do the optimal thing (4 bytes) and json will do the readable thing. The same goes for ipv6.

The only issue I see is that some might prefer to output a String in the canonical "127.0.0.1" form. For deserialization that's a no-brainer, simply offer a deserialization for Strings. But there's no way to serialize them this way.

[JohnHeitmann]

I like the octet array version.

Versus text: Once some version of #198 (mapping proxies) lands then serde can add pre-built text mapper proxies that folks can opt in to with annotations.

Versus u32: Octet arrays look better in JSON. Also, arrays have the same endianness universally.

The type I'm really interested in is Timespec, which has the same basic requirements as Ipv*Addr. Serde could by default offer a mapping that very directly models the native shape (i64, i32), and vend #198 mapping proxies with customizable formats for strings.

[erickt]

@JohnHeitmann / @oli-obk: Now that 0.7 has the ability to customize the output, in #242 I decided it'd be easier to just serialize addresses to a string, and leave a more optimized form up to the user.

[oli-obk]

just serialize addresses to a string, and leave a more optimized form up to the user.

We should leave this issue open to make sure we re-evaluate this decision after we see some usage of serde with these types.

[erickt]

@oli-obk: Sure. I've changed the title, and bumped the milestone to v0.8.

[dtolnay]

Any updates here? Have people mostly been happy with the string format? If so, we can close this.

[dtolnay]

If anyone requests this in the future, we could provide a crate of alternative de/serialization representations so that you could do something like:

#[serde(serialize_with="serde_alt::ipv6_to_tuple",
        deserialize_with="serde_alt::ipv6_from_tuple")]
ip: Ipv6Addr