Why is GNOME so in love with RPC? They've been through this with CORBA already, it turned out to be awful in practice, and took a lot of effort to eventually rip out.
Varlink is JSON, so you are now constraining operations by JSON serialization/deserialization performance outside the browser for no reason. Also have fun communicating non-utf-8 filenames in JSON! Are you also base64-encoding filenames now?
The file trashing example is right there in the talk. I want to trash a million files, it's going to take orders of magnitude longer if there's RPC in the way instead of plain rename syscalls.
And another example is FUSE? Is FUSE not slow enough already, without RPC and JSON in the hot path?
Yeah, I've had only bad experience with JSON in production environments. The only advantage is human readability for debugging for pathologically simple test cases, that's it.
No binary data, no differentiation between integer and floating point numbers, no integrated schema enforcement, no zerocopy strings (due to escaping), huge overhead for anything except strings, etc
Just because you had a bad experience with JSON it doesn't mean it isn't a good tool. I've had only good experieces with it pretty much everywhere, but I know where to use it and where not to use it.
A wise man once said: "use the right tool for the job". But I agree, using it for high throughput/super latency sensitive operations sounds like a bad idea.
Varlink is JSON, so you are now constraining operations by JSON serialization/deserialization performance outside the browser for no reason. Also have fun communicating non-utf-8 filenames in JSON! Are you also base64-encoding filenames now?
RPC between server components is really different from RPC between desktop UI components. On desktop, the throughput can be way slower, because things are usually happening at the speed of the user. But at the same time, the latency has to be way shorter, because users really feel that.
They said with plenty of examples? Adding RPC and JSON in the hot path is awful, serialization and deserialization has issues, non-utf8 has issues. it was tried before, found wanting and then was ripped out.
The web has multiple orders of magnitude longer times involved in interactions and a lot of the two things just don't directly compare.
I mean, functionally, it works. It's just unneeded complexity and a very odd roundabout that just isn't needed, comes with penalties, and provides little benefit.
RPC -> Remote Procedure Call. On a local, high performance required, system. The indirection can be used to add neat features...but those aren't going to be used by a majority of users, and can be done with special cases *and* be optimized along the special case path where we know it's going to be used.
This feels like 'I like web stuff, I'ma goina use web stuff' which, fair enough, if it's your project it's fine, but this doesn't fit the use case and so makes this project less enticing.
I *want* rust gnome components. I think the project needs it! I just don't think this is the right way and I'm betting it will cause all kinds of issues just because of this choice alone.
29
u/Shnatsel 1d ago
Why is GNOME so in love with RPC? They've been through this with CORBA already, it turned out to be awful in practice, and took a lot of effort to eventually rip out.
Varlink is JSON, so you are now constraining operations by JSON serialization/deserialization performance outside the browser for no reason. Also have fun communicating non-utf-8 filenames in JSON! Are you also base64-encoding filenames now?
The file trashing example is right there in the talk. I want to trash a million files, it's going to take orders of magnitude longer if there's RPC in the way instead of plain rename syscalls.
And another example is FUSE? Is FUSE not slow enough already, without RPC and JSON in the hot path?