`postcard-schema`: how to handle schemas conditional on `is_human_readable()`

[max-heller]

Some Serialize/Deserialize implementations (see e.g. uuid::Uuid) use different serde data model representations of the type depending on whether the underlying Serializer/Deserializer is human readable. For the most part, postcard should be able to think only in terms of the non-human-readable representation, but the distinction may matter for postcard-dyn in order to properly deserialize from human readable formats or serialize to human readable formats (e.g., json).

This could be captured in the schema as something like an IfHumanReadable { then: Type, else: Type } schema variant, though that feels somewhat clunky.

[max-heller]

Unfortunately postcard-dyn is probably out of luck here as there's no guarantee that serialized data can be transformed between its human-readable and compact forms, let alone in a universal way.

[Calsign]

For uuid::Uuid specifically, is there currently a way to round-trip through concrete types with postcard-dyn? Specifically, I would like to do this:

use postcard_schema::{Schema, schema::owned::OwnedNamedType};
use serde::{Deserialize, Serialize};
use uuid::Uuid;

#[derive(Debug, Serialize, Deserialize, Schema)]
struct Foobar {
    uuid: Uuid,
}

fn main() {
    let foobar = Foobar { uuid: Uuid::nil() };

    let postcard_encoded = postcard::to_stdvec(&foobar).unwrap();
    let schema = OwnedNamedType::from(Foobar::SCHEMA);

    let json_dyn1 = serde_json::to_value(&foobar).unwrap();
    println!("created by serde_json: {json_dyn1:?}");
    // this works
    let _concrete1: Foobar = serde_json::from_value(json_dyn1.clone()).unwrap();

    let json_dyn2 = postcard_dyn::from_slice_dyn(&schema, &postcard_encoded).unwrap();
    println!("created by postcard-dyn: {json_dyn2:?}");
    // this fails
    let _concrete2: Foobar = serde_json::from_value(json_dyn2).unwrap();

    // this also fails
    postcard_dyn::to_stdvec_dyn(&schema, &json_dyn1).unwrap();
}

This fails:

created by serde_json: Object {"uuid": String("00000000-0000-0000-0000-000000000000")}
created by postcard-dyn: Object {"uuid": Array [Number(0), Number(0), Number(0), Number(0), Number(0), Number(0), Number(0), Number(0), Number(0), Number(0), Number(0), Number(0), Number(0), Number(0), Number(0), Number(0)]}

thread 'main' panicked at src/bin/ex2.rs:24:64:
called `Result::unwrap()` on an `Err` value: Error("invalid type: sequence, expected a UUID string", line: 0, column: 0)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I understand that if I have a concrete type, I can deserialize directly into that concrete type, and if all I want is a generic serde_json::Value, there's nothing stopping me from doing that now. But I might want to be able to deserialize into a concrete type through postcard-dyn, in my case to implement custom message translation for backwards-compatible message decoding across schema changes. As of now the best idea I have to make that work with uuid::Uuid is to patch uuid.

[max-heller]

For uuid::Uuid specifically, is there currently a way to round-trip through concrete types with postcard-dyn?

@Calsign Currently? I don't believe so (without e.g. patching uuid to use the same representation regardless of the data format's human-readability as you mention).

Long-term, one way I could imagine this being made to work is to provide postcard-dyn with a set of concrete types that need special handling. Using a made-up API in the spirit of #194 (my other long-term dream):

postcard_dyn::Reserializer::new(schema)
    .special_case::<uuid::Uuid>()
    .reserialize(deserializer, serializer);

special_case::<uuid::Uuid>() would instruct postcard-dyn to use Uuid's Deserialize/Serialize impls instead of the generic Schema-based transformation whenever it expects to see a Uuid in the data (which it could tell based on its position in the schema).