Ben Christensen

There are a few outstanding items still being discussed so this remains open. PR: https://github.com/ReactiveSocket/reactivesocket/pull/154 Then a few changes @vjn and I have discussed and he will submit.

There is one open PR improving some wording in the spec, but otherwise @lehecka is starting to upgrading reactivesocket-cpp framing, and @lexs is beginning on reactivesocket-java. What is currently in...

Just merged the last open PR. Anything else needed? Has everyone done a full review of the framing? cc @tmontgomery @stevegury @NiteshKant @robertroeser @vjn @lehecka @lexs @yschimke My plan right...

We've had a storm of changes over the last couple weeks ... lots of new reviewers getting in their input as we approached v1, so thank you everyone for the...

If I remember correctly, the primary reason for this requirement was to allow efficient implementation of connection resumption. If the frame ordering is not deterministic and in ordered at the...

I think you should consider a rethink of resumption for this as you pursue it. Now that HTTP/3 is evolving, I think layering RSocket on top of it naturally is...

The use case we had was one where different streams had dramatically different costs of resumption, and for us, server-side memory cost (DRAM) was a big deal. So, instead of...

> @benjchristensen sounds like a more sophisticated use case for leasing. Not really. Leasing is about choosing what server to go to, and that's not what this was about. Resumption...

cc @abersnaze

Well that's an awkward callback then. It means it always gets scheduled. Annoying. I would default to computation like everything else does since this is pure compute, no IO for...