gRPCClient.jl release is ready

[AbrJA]

Hi @s-celles thank you for your effort in doing this package.

I just wanted to let you know that gRPCClient.jl v1.0.1 release is done.

If you need any help, let me know

[s-celles]

Hi @AbrJA

Currently I'm quite busy on other projects.
But don't hesitate, while I'm not available for this.
Fork, take the lead on this and submit PR.
If your work is good, we could even consider creating a GH org (or joining an existing one).
Room for improvements are, if I recall correctly

• Testing the lib with gRPCClient.jl
• Testing gRPC through TLS
• Make this lib be able to use either our HTTP2 module or a nghttp2 wrapper (see @csvance )
• Have HTTP2 module in a separate package (?)
• Look at tasks in ROADMAP.md and try to have upstream issues/improvements being fixed

Thanks for your help

[AbrJA]

Thank you @s-celles I will be working on that!

[s-celles]

4abc093#diff-98e2785c6db87ad5ec1b1f2e312c9c9a4b60898ca177cc5ad08b926131c05cf5 adds gRPCClient.jl as test dependency for integration tests.

Is there anything new @csvance about nghttp2 Julia wrapper?

And you @AbrJA ?

[AbrJA]

Hi @s-celles , sorry for the late response, I have been quite busy with work.

I'll check the current ROADMAP.md file and get started.

[s-celles]

Just noticed your post here. Sorry
Related:
JuliaWeb/OpenSSL.jl#67

Look at last version of develop
and this commit message bf322c4

I'm using now Reseau.jl https://github.com/JuliaServices/Reseau.jl

A big PR which remove a lot of code can be found #15

CI is failing because PureHTTP2.jl is not registered (it should come in a few days).

[AbrJA]

Sorry, I missed that. Understood, do you have the updated roadmap, or what tasks do you need help with? More testing?

[s-celles]

Yes I updated ROADMAP.md in #15 see https://github.com/s-celles/gRPCServer.jl/blob/a8fcf8940d2afe9e6af4ff646906903125f0e5e1/ROADMAP.md
I think some testing / examples with both backends PureHttp2.jl and Nghttp2Wrapper.jl could help.
Did you see work #14 from @GTrunSec ?
This problem should probably apply to PureHttp2.jl and we should verify that also

[AbrJA]

Ok, I will be working on it. Thank you

[csvance]

@s-celles did you see HTTP/2 support got merged in HTTP.jl? I didn't have time to get around to working with nghttp2, but it seems like the blockers to a functional gRPCServer are very small now. I would very much like to be able to have a functional gRPCServer library for the new inference server I'm working on. I'm on vacation right now but when I get back I can lend a hand.

JuliaWeb/HTTP.jl#1244 (comment)

[csvance]

@s-celles are you still working on this? I have a fully working implementation that passes all of the gRPCClient.jl load tests. It's still not ready to publish, but its working and the interface is pretty clean (inspired by both gRPCClient.jl and Oxygen.jl). https://github.com/csvance/gRPCServer.jl

[s-celles]

I have been quite busy recently.
My gRPCServer.jl version supports currently 2 differents HTTP-2 backends. One named PureHTTP2.jl and an other one named Nghttp2Wrapper.jl
My version is being tested by an OSCP @GTrunSec (I think he essentially tried with nghttp2) which is something quite important.
I think supporting HTTP-2 from HTTP.jl should be quite easy to add (but I still have 2 busy weeks). Sorry.
In any case I think it will be better to have gRPCServer in a Github org. Probably next to gRPCClient.jl in JuliaIO?
What is your opinion about future?

[s-celles]

gRPCServer.jl rely on Reseau.jl

[csvance]

@s-celles I'm not super particular on the actual logistics / where things are hosted / who publishes gRPCServer.jl, but I want something that is battle tested / production grade. I develop FDA regulated Software as a Medical Device. So I don't really care whether its nghttp2 or HTTP.jl under the hood, it needs to keep running and never hang under any circumstances. That was the goal with gRPCClient.jl. Do one thing and do it exceptionally well.

I'll probably develop mine independently for now. There is room for multiple approaches in the ecosystem. But this is an immediate business driven need for me at this point more so than actually publishing the package to the registry, hence why I am rushing ahead on this. Of course if I had something production grade I would register it so others in a similar situation could use it too.