Re: Pure rust ostree FUSE implementation
- From: Zeeshan Ali <zeeshanak gnome org>
- To: will williammanley net
- Cc: ostree-list <ostree-list gnome org>
- Subject: Re: Pure rust ostree FUSE implementation
- Date: Thu, 20 Aug 2020 18:15:13 +0200
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? 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.
gvariant-rs makes allocations explicit and can operate in no-std and no-alloc environments. It's designed
for reinterpreting byte buffers as GVariant types for fast and light access - as such control over
allocations and alignment is exposed in the API, while zvariant doesn't expose such control.
Cool, that is indeed a big advantage for very low-end embedded targets.
Just FYI, nostd is very much something on our radar
(https://gitlab.freedesktop.org/zeenix/zbus/-/issues/22). I would also
very much love to support noalloc, although that would be much more
challenging. However, I'm not sure our API/approach should be a hurdle
there as serde itself supports both features.
My intention is to extend the GVariant schema compiler[1] with a backend for Rust using gvariant-rs.
[1]: https://blogs.gnome.org/alexl/2020/01/14/introducing-gvariant-schemas/
Cool.
(GVariant is a superset of DBus...I think it boils down to the "maybe"
type only existing in GVariant)
To be specific: The GVariant data model is a superset of DBus' in that you can round trip DBus messages to
GVariant and back losslessly, but the serialisation format is different. GVariant, unlike DBus, supports
O(1) array and struct element access.
There's probably a better forum for this...it looks like the gtk-rs
developers use Matrix. Or we could try to summon the zvariant
developers here.
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. :)
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.
--
Regards,
Zeeshan Ali
https://gitlab.freedesktop.org/zeenix/zbus/-/issues/22
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]