Streaming

[Tewr]

Implement Stream support in the service contract (either as an argument or as a return type).

[HillPhelmuth]

Does this include support for streams created and used only inside a service?
The service I'm attempting to run inside a worker uses roslyn to compile code and emit a result from the compilation, which requires a stream input. The stream exists only briefly inside the service. When I run the service from a worker, I receive the following exception:

FATAL UNHANDLED EXCEPTION: System.ArgumentException: Stream must support read and seek operations.

I'm not particularly familiar with Web Workers, so I'm not sure if this is a Web Worker issue, a BlazorWoker limitation, or if I've just made a mistake in implementation.
I use BlazorWorker with a few other services without issue, In fact, it works great, and I appreciate the work you've put into this.

[Tewr]

This issue is for supporting Streams in the service contract (either as an argument or as a return type).

Just using a stream inside the worker should work just fine, there is no difference from blazor really other than that the blazor assemblies are not loaded by default inside a worker. But you currently can't create the stream inside blazor and pass it to the worker, or the other way around.

Check the CanSeek and CanRead properties of your stream.

[Jack-Edwards]

Is it still the case that we can't pass streams from the Blazor client to the service worker? I'd really like to be able to pass a stream to the worker in order to simulate streamed file downloads from a server. Similar to what several JS libraries have accomplished. https://www.npmjs.com/package/streamsaver

[Tewr]

Hello.

Currently, you can only pass serializable objects over the "service border". A System.Io.Stream is not serializable, so for it to be a part of the service contract, specific support is necessary.

However, you seem to be talking about a "service worker". When I use the word service in this thread, I'm simply talking about a dotnet class or interface "offering a service". This library uses web workers, not service workers. I say this because just supporting Streams on the service border is not enough for simulating server downloads/streaming.

Something similar to streaming can be accomplished today using event messaging. That might even be the base for the future implementation.