for grpc, we should add to dproto (which is pretty good protobuf library for D but lacks grpc) instead of starting from scratch, see https://github.com/msoucy/dproto/issues/113 [your advice/opinions on integrating with grpc?]
On Mon, Jan 22, 2018 at 12:24 PM, Adrian Matoga via Digitalmars-d <[email protected]> wrote: > 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. >
