gRPC in D good idea for GSOC 2018?

[Timothee Cour]

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
<digitalmars-d at puremagic.com> 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.
>