gRPC in D good idea for GSOC 2018?

Timothee Cour thelastmammoth at gmail.com
Mon Jan 22 07:15:34 UTC 2018


> Do we even have protobuf package?

https://github.com/msoucy/dproto
it could receive some attention, there are pending issues

for RPC I've been using msgpackrpc since no gRPC was available. But
would be nice to have gRPC.

NOTE: capnproto is a very interesting newer alternative to protobuf;
https://github.com/capnproto/capnproto-dlang shows:
Missing RPC part of Cap'n Proto.
helping out capnproto project (esp around RPC) could be another idea.

we definitely need a good way to do RPC in D, otherwise hard to
integrate D with other services.

> I would consider them awful in a sense that there is no foundation to build them on. At best it will be a self-serving artifact poorly fitting with anything else.

But it would enable using D in places that were not previously
possible (integrating with services); we could imaging providing a
(semi) stable interface for grpc in D code and change implementation
to use better foundations later




On Sun, Jan 21, 2018 at 9:54 PM, Dmitry Olshansky via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Monday, 22 January 2018 at 04:40:53 UTC, Andrew Benton 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
>>
>>
>> An http/2 and gRPC solutions is probably necessary with tools like
>> linkerd, envoy, and istio if D wants to be competitive in service mesh and
>> distributed applications.
>>
>> http/2 and/or gRPC are both excellent ideas for GSoC 2018.
>
>
> I would consider them awful in a sense that there is no foundation to build
> them on. At best it will be a self-serving artifact poorly fitting with
> anything else.
>
> There is not even a standard way on handling IO as of yet.
> Basically do we want fiber-aware IO or blocking IO or explicit async with
> future/promise?
>
> Do we even have protobuf package?
>
>



More information about the Digitalmars-d mailing list