GNOME.org
 

Re: Pure rust ostree FUSE implementation

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.


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.


If you meant the API where you pass the signature yourself: See all
the "_for_signature" suffixed functions here:
https://docs.rs/zvariant/2.0.1/zvariant/index.html#functions

If you meant the blanket implementations:
https://docs.rs/zvariant/2.0.1/zvariant/trait.Type.html#foreign-impls
(Note: Serde implements Serialize for those types so we only need to
implement Type to add signatures).


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.


I can relate but since zbus+zvariant were well advertised from the
beginning and people have been looking forward to making use of them,
"Why didn't you try and combine your efforts with existing ones?" is a
very valid question people will ask, I'm afraid.

-- 
Regards,

Zeeshan Ali
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]