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 < [email protected]> 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 > > Am Do., 13. Juni 2019 um 16:47 Uhr schrieb Kenton Varda < > [email protected]>: > >> 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 >> >> On Thu, Jun 13, 2019 at 1:19 AM <[email protected]> wrote: >> >>> 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 >>> >>> -- >>> 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 [email protected]. >>> 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 >>> <https://groups.google.com/d/msgid/capnproto/f98c6f41-709b-4c63-a540-0e3f4b2c583d%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. 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/CAJouXQ%3DrsQmHQu17-SS2GR67cvbvcMzVSwng%2Bog%2BGw8fg0sT9w%40mail.gmail.com.
