Consider SignalR Pull Model / Streaming for JavaScript and Java client

[TanayParikh]

As a part of #30289 / #33491 we didn't leverage SignalR's native streaming capability as we wanted to delay sending additional data chunks until the ones sent had been consumed by the server. Without this, the client could queue the entire stream at once (via subject.next(nextData)) thereby blocking interactivity till the stream was transferred. This would in turn present a breaking change for certain functionality like file uploads. Instead we took a send/invoke based approach where we send X chunks, and then invoke every X+1 chunks to get a "heartbeat" for the stream, and allow other requests to interrupt the transfer.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.