Cap'n Proto for .NET Core

[christian....@gmail.com]

Hi folks,

I recently contributed a .NET Core implementation for Cap'n Proto:

https://github.com/c80k/capnproto-dotnetcore

It it entirely written from scratch (no native bindings / CLI) and was cross-tested with recent release 0.7.0 (to some basic extent)

Features so far:

• Capnp.Net.Runtime supports all kinds of serialization and Level 1 RPC
• capnp-csharp is the compiler backend generating C#

Maybe somebody is interested. I appreciate your feedback.

Regards

Christian

[Kenton Varda]

Wow, this is huge!

I dug in a bit and see you even implemented disembargos. Nice.

Are there any docs on how to use it? Looks like the readme is pretty empty right now.

Did you have to do anything unusual to map Cap'n Proto to C#? Any war stories?

-Kenton

--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+...@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.
To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/f98c6f41-709b-4c63-a540-0e3f4b2c583d%40googlegroups.com.

[Kenton Varda]

Hi Christian,

I'm re-adding the list to this mail since I think people will find the discussion interesting.

(Sorry for my slow reply, I'm technically on parental leave...)

Yes, I imagine async/await makes Cap'n Proto RPC much, much nicer. Can't wait to have it in C++.

Using domain objects rather than readers/builders is a reasonable decision. I've long wanted to support that as an alternative in C++, for cases where performance isn't as critical.

I do think promise pipelining and e-order (what embargoes are needed for) are very much worth the effort -- they allow application code to be so much simpler.

I'd be interested to know the exact sequence of messages that the C++ code is producing that you think seems wrong.

Let me know if/when you'd like me to link your implementation from capnproto.org/otherlang.html !

-Kenton

On Thu, Jun 13, 2019 at 2:01 PM Christian Köllner <christian....@gmail.com> wrote:

Hi Kenton,

you're totally right - the documentation is still work in progress. A good starting point might be the test suite which is integrated inside the VS solution. It will give you an impression on how to use the framework. And at least the vast majority of all public classes, interfaces and methods is documented. When I find the time, I also intend to provide nuget + vcpkg deployments.

The compiler backend is just an executable. After deploying it out of its VS solution, you will be able to use it together with capnpc.

Nice things to mention: I found the explanations on capnproto.org and also the comments inside the schema files extremely helpful 

IMO, .NET async concepts (especially Task<T> and the await operator) play very well with the Cap'n Proto mindset. I even find the resulting .NET APIs a bit more fluent compared to the C++ API. For passing method parameter types of RPC interfaces, I use domain classes. I.e. the object does not map directly to the underlying message. This provides more convencience but comes at the price of non-zero serialization overhead (not infinitely faster anymore, sorry for that). It was even possible to implement promise pipelining with .NET extension methods, mapping a Task<T> to T (where T is a capability interface, look at the "Impatient" class). Tail calls cannot be made explicitly, but the underlying runtime tries its best to infer them automatically: when a skeleton invocation returns a Task<T> which is known to be a question to the same party, we can interpret that question as a counterquestion.

Embargos were really hard, and I still have some doubts that I understood them deeply enough. Personally, I'm wondering whether it's really worth the runtime data structure management overhead of promise pipelining + embargos instead of ... well, just waiting until that thing resolves / everything returned.

So far, it is worrying me that one test case ("TailCallClient") is currently failing. This test case is a ported version of the original Cap'n Proto "TailCall" test, with the client being the original C++ implementation, and the server being the .NET Core implementation. It's the C++ side which seems to get a call sequence in wrong order, but I can't figure out what the .NET side is doing wrong. Yes, there is am embargo involved, send from C++ to .NET. But the disordering seems to happen before the .NET side even receives it.

Regards

Christian

[Christopher Wheeler]

Awesome work,

Out of curiosity, why didn't you implement it in .NET standard.  I'm not a .NET developer primarily, so I"m trying to figure out how the community views it.

-Chris

[christian....@gmail.com]

Christopher, providing it for .NET Standard should be straightforward (haven't tried it since I'm currently in holidays without VS available, just an old tablet). The implementation is entirely C#, and I don't see any reason why the code shouldn't compile to a .NET Standard assembly. I picked .NET Core mainly because of its "en vogue" factor. However, deploying the Capnp.Net.Runtime assembly for .NET Standard seems highly reasonable.

[Christopher Wheeler]

I've got a branch on my repo that implements this, I've discovered that a lot of the test won't run on macOS, so I need to test it on a PC, I'll submit a PR shortly

[Kenton Varda]

Hi Christian,

Is it OK for me to link your github repo from capnproto.org/otherlang.html now? Or would you prefer to hold off? Please let me know!

-Kenton