gRPC in D good idea for GSOC 2018?

[yawniek]

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).