Hi Will and everyone,
I think this discussion is going way off-topic for this list so I'll
keep this as short as possible. We can communicate in private or on
our IRC channel if needed.
On Tue, 25 Aug 2020 at 12:52, Will Manley <will williammanley net> wrote:
>
> On Thu, 20 Aug 2020, at 17:15, Zeeshan Ali wrote:
> > Hi Will and everyone,
> >
> > On Thu, 20 Aug 2020 at 00:05, Will Manley <will williammanley net> wrote:
> > > > > https://docs.rs/gvariant/0.3.0/gvariant/
> > > >
> > > > Nice. Have you compared with https://lib.rs/crates/zvariant ?
> > >
> > > Yes. At this point zvariant implements the DBus serialisation format, although I understand that it will support GVariant in the future and the GVariant implementation has made good progress.
> > >
> > > I'm no expert in zvariant, so take any opinions here with a pinch of salt...
> > >
> > > My library makes some different design decisions to zvariant. zvariant derives the GVariant types from the Rust types you give it. gvariant-rs requires that these types are explicitly called out in GVariant format. I think this is the key difference in approach. IMO data takes priority over code, as it's easy to change code, but hard to change data that's been saved on a disk somewhere - so I always like serialisation formats to be explicit.
> >
> > While that is a pretty fair assessment, I'm not sure I follow your
> > conclusion. You mean zvariant's approach somehow makes it impossible
> > to load some existing gvariant data?
>
> I don't mean that. I'll clarify what I do mean with an example. Maybe you can correct me if I've misunderstood.
>
> With zvariant (from README):
>
> let v = vec!["hello", "world!"];
> let encoded = to_bytes(ctxt, &v).unwrap();
> let decoded: Vec<&str> = from_slice(&encoded, ctxt).unwrap();
>
> with gvariant-rs:
>
> let v = vec!["hello", "world!"];
> let encoded = gv!("as").serialize_to_vec(v);
> let decoded = gv!("as").from_bytes(&encoded);
>
> What I mean is that gvariant-rs includes the target serialisation signature in GVariant format. i.e. it explicitly says "as", rather than deriving it from the rust type. This is what I mean by the data taking priority. Doing it this way means that a change to the code is unlikely to accidentally change the format that is being serialized. It also means we can accept any `IntoIterator<&str>` when serialising, and we avoid issues like rust arrays being serialised as tuples rather than GVariant arrays. Of course, maybe I've misunderstood how zvariant works?
>
> This is what I like about the GVariant schema approach. The on-disk format is explicitly specified and code is derived from that.
Ah ok. Given that this is how all serde serializers work and that
serde is **the** serialization API in the Rust world, I wonder if this
issue is actually a very common one. Besides, if one needs to
serialize a type differently than how serde/zvariant will serialize it
as, it's not at all hard to create a NewType struct and manually
implement serde::ser::Serialize and zvariant::Type for it.
Easy also for the caller to add a static check for the signature.
We could add some convenience API for that too. (to_bytes_check_signature?)
