In the world of inter-process communication, a new C library called vali has emerged to implement the Varlink protocol, sparking lively discussion among developers about whether simplicity trumps functionality in RPC systems. The community is actively debating Varlink's design choices and how it compares to established alternatives like gRPC and D-Bus.
The Simplicity Versus Features Debate
The tech community appears divided on Varlink's minimalist approach. Some developers appreciate its straightforward design using JSON over Unix sockets, while others question whether it's too simple for practical use. One commenter noted that compared to more complex systems like gRPC or Cap'n'Proto, Varlink sacrifices certain features for simplicity. The protocol's lack of unsigned or sized integers has raised concerns among developers who work with precise numerical types.
It's JSON with some simple idea of RPC added to it. With the main idea apparently being that it is human-readable. But compared to gRPC or CapnProto, you lost compile-time type checking.
This sentiment reflects a common concern that without proper tooling, developers might encounter runtime errors that could have been caught during compilation in more sophisticated systems.
Community-Noted Limitations:
- No unsigned integer types
- No sized integer types
- Incompatible with JSON-RPC despite structural similarities
- Runtime type errors possible without code generation
Code Generation as the Type Safety Solution
The vali library addresses type safety concerns through comprehensive code generation from interface definition files. This approach automatically creates client and server code that handles JSON encoding and decoding, providing the compile-time type checking that some community members felt was missing. The generated code includes separate structures for input and output parameters, ensuring clear separation between request and response data. This design choice also maintains backward compatibility when interfaces evolve over time, as new optional fields can be added without breaking existing implementations.
The Local IPC Focus
Unlike network-oriented RPC systems, Varlink specifically targets local inter-process communication, positioning itself as a simpler alternative to D-Bus rather than competing directly with internet-scale solutions. This focus explains design decisions that might seem limiting for networked applications but work well for local services. The community discussion reveals that several developers have implemented similar concepts in other languages, including C++/Qt and C++ with asio, indicating broader interest in Varlink's approach to local RPC.
Varlink Protocol Key Characteristics:
- Uses JSON over Unix sockets for local IPC
- Simple request-response model with optional multiple replies
- Interface definition language for code generation
- Focuses on local services rather than networked applications
Asynchronous Handling and Memory Management
Vali's asynchronous design has drawn both praise and criticism. The library allows services to handle multiple clients concurrently by deferring responses, which prevents blocking during long operations. However, the memory ownership model for response structures has raised questions. One developer expressed concern about how response memory gets allocated by the caller library, handed over fully owned to functions, and then consumed by response functions. This approach differs from patterns common in languages like Haskell and Rust that have more explicit ownership semantics.
Alternative Implementations Mentioned:
- varlink-cpp (C++ with asio and nl-json)
- QtVarlink (C++/Qt implementation by KDE developers)
JSON-RPC Compatibility Questions
Some community members have questioned why Varlink, while structurally similar to JSON-RPC, chose to be incompatible with it. This design decision means existing JSON-RPC tooling and libraries can't be used with Varlink services, potentially limiting adoption. The human-readable JSON format, while theoretically beneficial for debugging, appears to offer little practical advantage according to developers who've used the protocol in real projects.
The ongoing discussion highlights the eternal tension in technology design between simplicity and capability. While vali brings much-needed code generation to the Varlink ecosystem, the broader conversation suggests that the protocol itself may need to address certain limitations to gain wider adoption among developers working on local IPC solutions.
Reference: Announcing vali, a C library for Varlink