Allow representation to differ between human-readable and binary formats

[dtolnay]

As an initial brainstormed approach to give an example of what I have in mind:

trait Serializer {
    /* existing associated types and methods */

    fn serialize_readable_or_compact<T>(self, t: T) -> Result<Self::Ok, Self::Error>
        where T: SerializeReadable + SerializeCompact;
}

trait SerializeReadable { /* just like Serialize */ }
trait SerializeCompact { /* just like Serialize */ }

... and similar for deserialization.

The idea is that chrono::DateTime, std::net::IpAddr etc can serialize themselves as a string in JSON and YAML but compact bytes in Bincode. Currently a SocketAddrV6 takes up to 55 bytes to represent in Bincode but should only be 18 bytes.

[clarfonthey]

I think I'd describe data in this form as a "blob;" formats like JSON can only store arbitrary data as strings, whereas formats like bincode can store any arbitrary bytes. I have an idea for how I'd implement this and I'll post it later once I write it up.

[clarfonthey]

Perhaps like this?

trait Serializer {
    // existing stuff
    fn serialize_blob<T>(self, t: T) -> Result<Self::Ok, Self::Error> where T: SerializeBlob;
}

trait SerializeBlob: Display {
    fn fmt_bytes<W>(&self, writer: W) -> io::Result<()> where W: io::Write {
        write!(writer, "{}", self)
    }
}

I'm open for ideas on how to do this without requiring libstd. I'd rather it not be too complicated, though.

[dtolnay]

What do you see as the advantages of that approach? Here are some disadvantages:

• If you are calling serialize_blob, you want the representation to be different in bytes form vs string form so the default implementation of fmt_bytes is never what you want. Otherwise you would just use collect_str instead of serialize_blob.
• Only supports string/byte representations rather than a more general concept of readable and compact, which may be a non-string in the readable case (for example a map) and non-bytes in the compact case (for example a tuple of integers for an IP address).

[dtolnay]

Of course here is the KISS approach:

trait Serializer {
    /* existing associated types and methods */

    #[inline]
    fn is_human_readable() -> bool { true }
}

fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
    where S: Serializer
{
    if S::is_human_readable() {
        serializer.collect_str(self)
    } else {
        serializer.serialize_bytes(self.as_bytes())
    }
}

[clarfonthey]

I like it, although I think that it'd be nice to have a method that enables the user to test both branches without having to change anything in the serializer.

Perhaps we could add a separate serialize_binary method that defaults to delegating to serialize and is called by the serializer if appropriate?

[Marwes]

@clarcharr

I like it, although I think that it'd be nice to have a method that enables the user to test both branches without having to change anything in the serializer.
Perhaps we could add a separate serialize_binary method that defaults to delegating to serialize and is called by the serializer if appropriate?

Both Serializer and Serialize implementations still need to be modified to support this case though so there is not really anything gained from that approach?