Re: Pure rust ostree FUSE implementation

["Will Manley" <will williammanley net>]

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.

> Just to be clear, zvariant does
> require you to provide type signature of the data for both serializing
> and deserializing (I tried very hard to avoid that but it was
> impossible because of Variant type mainly). However, we do our best to
> make it as painless as possible through blanket trait implementations
> and zvariant_derive macros.

Could you provide an example?  I didn't see it in the docs.

> > I've had a few conversations with @zeenix (the zvariant author) on github issues. I wouldn't want to put 
> > words in his mouth, but I sense a degree of frustration that I chose to implement my own GVariant crate 
> > rather than adding GVariant support to zvariant.  Ultimately I wanted to explore the design space, and 
> > gvariant-rs is what I made.  Creating it was educational for me and the intention is that it will 
> > hopefully be useful for others, in particular for ostree.  It was designed with ostree in mind - in 
> > particular making changes like #1643 or #1408 easier.
>
> You're correct but frustration isn't coming from you going your own
> way but rather that you didn't reach out to us and talk about possible
> collaboration first. That alone wouldn't be frustrating either but
> seems in the last several months there has also been a bunch of new
> D-Bus crates as well and none of the authors trying to collaborate
> first. Also, I couldn't help but notice that most (if not all) of
> these crates came after I started giving talks about zbus and zvariant
> at conferences. My hope was to get help, not create competitions so
> you can understand why I'd feel frustrated. :)

That's understandable and understood.

> Having said that, it's yours (and all those authors') right to do
> whatever they feel is right. On the positive side, some competition is
> always good and we can learn from each other. I know I already gained
> some invaluable insights about GVariant format from you.

Please also understand how disheartening it is to work on something, be proud of it an feel like you've done 
a good job both quality and documentation wise - even finding bugs in the reference implementation, then to 
release it to the world only to be greeted mostly with indifference, and the only feedback you receive is 
"why didn't you do this instead?".  We're all human here.

Thanks

Will