8 ms·

So... it looks like this is an RPC protocol, similar to JSON-RPC, but the word "RPC" doesn't appear anywhere on the homepage or the FAQ. And it has an interface

So... it looks like this is an RPC protocol, similar to JSON-RPC, but the word "RPC" doesn't appear anywhere on the homepage or the FAQ. And it has an interface description language, similar to Protobuf. It seems like it might be a nice middle ground between Protobuf (strongly-typed, specified) and JSON-RPC (human-readable, doesn't need a special library). But requiring clients to use a new RPC format is still a tough sell. What are the main advantages of Varlink over more mainstream RPC formats?

1_player 7y ago
I read about Varlink while taking a look at podman, which uses it as a remote interface [1]. I don't think it does anything _much_ different than protobuf or JSON-RPC but simply IMO tries to create a common interface to interact with software or daemons. Protobuf is by itself just a protocol and encoding format, while Varlink wants to create a generic network-independent RPC interface you can easily access from your shell. I'm not sure I understand what's the underlying transport protocol (HTTP? custom one?) but having JSON as encoding format is pretty nice, any shell script could talk with it and it's eas(ier) to inspect. It looks like a generalised version of DBus, without requiring a central daemon. I think it looks pretty cool. EDIT: also it seems to natively handle subscriptions/polling for changes. EDIT 2: the transport protocol is just read/writing raw JSON to the file descriptor/socket, see the strace snippet at the bottom of https://github.com/varlink/linux-varlink https://github.com/varlink/linux-varlink 1: https://github.com/containers/libpod/blob/master/cmd/podman/varlink/io.podman.varlink https://github.com/containers/libpod/blob/master/cmd/podman/...
- juped 7y ago
  >having JSON as encoding format is pretty nice, any shell script could talk with it and it's eas(ier) to inspect Why do people say things like this? The only format unix shell can reliably understand is tab-separated value.
  - 1_player 7y ago
    The shell can't speak HTTP either, but all OSes ship with a command line HTTP client. My point is that in 2019 JSON is such a common format _most_ people have or should have a JSON client encoder/decoder installed in their /bin, though I'm not sure any OS ships with any by default. To be fair, I have jq installed and I have no idea how to use it.
    - Spivak 7y ago
      I really love the jq language but I totally agree that the complexity skyrockets once you peek at the 'advanced' features because this neat little query language turns into a full programming language with io, variables, modules, functions. Very similar to AWK. If you want something that is just a good query language then I would highly recommend JMESPath. It's a little harder to grok initially but the spec is extremely detailed, comes with examples, and there's libraries for all the 'popular' programming languages. A good CLI tool that wraps the Go library is https://github.com/jmespath/jp https://github.com/jmespath/jp

1_player 7y ago

I read about Varlink while taking a look at podman, which uses it as a remote interface [1]. I don't think it does anything _much_ different than protobuf or JSON-RPC but simply IMO tries to create a common interface to interact with software or daemons. Protobuf is by itself just a protocol and encoding format, while Varlink wants to create a generic network-independent RPC interface you can easily access from your shell. I'm not sure I understand what's the underlying transport protocol (HTTP? custom one?) but having JSON as encoding format is pretty nice, any shell script could talk with it and it's eas(ier) to inspect. It looks like a generalised version of DBus, without requiring a central daemon. I think it looks pretty cool. EDIT: also it seems to natively handle subscriptions/polling for changes. EDIT 2: the transport protocol is just read/writing raw JSON to the file descriptor/socket, see the strace snippet at the bottom of https://github.com/varlink/linux-varlink https://github.com/varlink/linux-varlink 1: https://github.com/containers/libpod/blob/master/cmd/podman/varlink/io.podman.varlink https://github.com/containers/libpod/blob/master/cmd/podman/...

juped 7y ago
>having JSON as encoding format is pretty nice, any shell script could talk with it and it's eas(ier) to inspect Why do people say things like this? The only format unix shell can reliably understand is tab-separated value.
- 1_player 7y ago
  The shell can't speak HTTP either, but all OSes ship with a command line HTTP client. My point is that in 2019 JSON is such a common format _most_ people have or should have a JSON client encoder/decoder installed in their /bin, though I'm not sure any OS ships with any by default. To be fair, I have jq installed and I have no idea how to use it.
  - Spivak 7y ago
    I really love the jq language but I totally agree that the complexity skyrockets once you peek at the 'advanced' features because this neat little query language turns into a full programming language with io, variables, modules, functions. Very similar to AWK. If you want something that is just a good query language then I would highly recommend JMESPath. It's a little harder to grok initially but the spec is extremely detailed, comes with examples, and there's libraries for all the 'popular' programming languages. A good CLI tool that wraps the Go library is https://github.com/jmespath/jp https://github.com/jmespath/jp