Open Tewr opened 4 years ago
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.
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.
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
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.
Implement Stream support in the service contract (either as an argument or as a return type).