On Monday, 15 January 2018 at 19:28:08 UTC, Ali Çehreli wrote:
I know a project where D could benefit from gRPC in D, which is
not among the supported languages:
https://grpc.io/docs/
Do you think gRPC support is worth adding to GSOC 2018 ideas?
https://wiki.dlang.org/GSOC_2018_Ideas
Ali
I can share a fresh experience from mentoring a student in a
similar (also RPC) project last summer. We built native D-Bus
bindings in D based on libasync. The student had had no previous
experience with D or RPC, and within ~2.5 months of focused work
she implemented the following:
1. (de)serialization of all D-Bus data types, including the use
of compile-time reflection to recursively marshall structs,
arrays, and variants. Except Variant, for which we decided to
make our own D-Bus-specific tagged union type, all other D-Bus
types are mapped to built-in D types.
2. A class to connect to the bus via libasync sockets, read the
incoming messages and dispatch them to the registered handlers,
and send messages to the bus.
3. Proxy (client) and server class templates that generate all
the code necessary to make the remote calls look almost like
local ones (the return value/out arguments are passed to a
delegate that handles the output instead of being returned
synchronously).
So, more or less an equivalent of vibe.d's REST interface
generator, only with fewer customization points.
There were still some opportunities for refactorings and
optimizations, so I wouldn't consider it production ready. Also,
some planned features weren't implemented, such as a more
convenient way for handling signals or allowing transports other
than unix sockets on libasync. On the other hand, what we have is
almost 100% covered with unit tests. This not only made adding
successive layers quite pleasant, as little (if any) debugging of
previously written stuff was ever necessary, but also helps to
keep the stuff working as we modify it.
Based on my experience, I'd say that implementing gRPC may be of
a right size for a GSoC project, as long as you split it into
smaller components/layers, prioritize them, and focus on having
at least the basic stuff usable and tested, instead of expecting
it to cover all usage cases and be heavily optimized.
