Though my Haskell and Rust primed brain really dislikes the way ownership of the memory allocation for the response struct works.
It gets allocated by the caller (library), handed over to the function fully owned, and then gets consumed by the response function?
More realistically, adding HTTP where it is not needed adds unnecessary complexity.
NewJazz•3mo ago
emersion•3mo ago
sam_bristow•3mo ago
This might enf up being be fine, but it gave me pause when I looked at it previously.
wolletd•3mo ago
We've been using Varlink for one project, but I've never found myself in a situation where I had any benefit from the data being JSON. You rarely read the raw data. But compared to gRPC or CapnProto, you lost compile-time type checking and now you need 10mins of testing a vending machine before you get a "key not found"-error because you missed one spot on renaming.
Also, I've written varlink-cpp building on asio and nl-json at some point: https://github.com/wolletd/varlink-cpp. But as our varlink usage declined, it never found much usage and isn't maintained.
emersion•3mo ago
jauntywundrkind•3mo ago
The Linux ecosystem was using D-Bus for basically everything. But there was some need for IPC in early boot, before any D-Bus brokers were started.
Varlink was the answer, as a simple direct (vs DBus's broker mediated) IPC.
NewJazz•3mo ago
At the end of the day, local or remote, it is all just pushing data over sockets, no?