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 On Tue, Jun 18, 2019 at 6:58 AM Kenton Varda <[email protected]> wrote: > 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/CAJouXQmRcSPxgdmRzTRB3jJdLQajbM-WCpnNXAGeJxOLxuJT%3DA%40mail.gmail.com.
