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

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

Also, the deadline is in 1 week.

On Tuesday, 16 January 2018 at 17:58:40 UTC, jmh530 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
>
> Also, the deadline is in 1 week.

Yes it's a good idea for GSoC18 and we still accept ideas. Reply here if you have more ideas ;-)

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

Problem here is that D lacks a proper http/2 stack.
unfortunately due to time constraints my libh2o binding project got stuck.

Imo the real problem with D is still that phobos does not provide the important building blocks for today modern infrastrucutre:

- fast and standardized eventloop compatible with Ds concurrency primitives
- network protocol libs/ bindings ( http, http/2, tls, dns )

until there is effort to do this D will continue to be an ecosystem of hacks.
I really like vibe.d but it comes with a lot of problems and it has the focus of providing a usable web framework and not implementing protocols in a fast and reusable way.

so as long as "management" does not decide that internet protocols is something important in D nothing useful will come out. Just look how beautiful Golangs protocol implementations are and the whole ecosystem that focused effort spawned.

On 01/19/2018 02:14 AM, yawniek wrote:

> Just look how
> beautiful Golangs protocol implementations are and the whole ecosystem
> that focused effort spawned.

I agree and do have first-hand experience with that but I'm not experienced enough in this field to come up with a modern solution. If it were left to me, I would start looking at Go and Python solutions but I fear I wouldn't see design decisions that could have been better.

Could you please summarize what needs to be done and in what order. I would be happy to take active part in this effort.

Thank you,
Ali

On Friday, 19 January 2018 at 18:34:31 UTC, Ali Çehreli wrote:
> On 01/19/2018 02:14 AM, yawniek wrote:
>
> > Just look how
> > beautiful Golangs protocol implementations are and the whole
> ecosystem
> > that focused effort spawned.
>
I have said this here before.

> I agree and do have first-hand experience with that but I'm not experienced enough in this field to come up with a modern solution. If it were left to me, I would start looking at Go and Python solutions but I fear I wouldn't see design decisions that could have been better.
>
> Could you please summarize what needs to be done and in what order. I would be happy to take active part in this effort.
>
> Thank you,
> Ali

On Friday, 19 January 2018 at 18:34:31 UTC, Ali Çehreli wrote:
> On 01/19/2018 02:14 AM, yawniek wrote:
> Could you please summarize what needs to be done and in what order. I would be happy to take active part in this effort.

well,  my personal opinion this should be designed/decided on a green field and not again make the mistake to try to include too much that is just laying around. i think vibe.d's eventcore may (or may not) be too opinionated and providing too much:

1a. define an overal strategy how/where protocols should be implemented and whether to focus on speed or "elegant" implementations.

1b. define how high performance servers should ideally be implemented and how that works together with D's concurrency models. plus provide the necessary things such as streams/ranges. ideally endorse/include/create one primary eventloop implementation or interface. possibly rusts tokyo.rs could be an inspiration?
https://tokio.rs/docs/getting-started/tls/

2a. create reference implementations for a http parser or e.g. port something like picohttpparser https://github.com/h2o/picohttpparser but this should adhere to the approach defined in 1.


3. implement crypto functions. e.g. port picotls ( https://github.com/h2o/picotls ) but also provide/maintain proper openssl bindings.

4. implement http/2  grpc

also, think about what happens when the world starts switching to quic, the ietf wg makes good progress from what i saw.


a totally different approach/decision would be to say, that D is a glue language and one should use C libraries (libuv, openssl, picohttpparser). but then i think tooling for integrating those should be improved/standardized (e.g. package manager, binding automation).

On Friday, 19 January 2018 at 10:14:15 UTC, yawniek 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
>
> Problem here is that D lacks a proper http/2 stack.
> unfortunately due to time constraints my libh2o binding project got stuck.

Have you seen Etienne's libhttp2?

http://code.dlang.org/packages/libhttp2

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.

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?