You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In issue #59, @Acconut called out that it doesn't makes sense for tus-js-client to support the creation-defer-length extension until tusd supports it. However, since then, tusd has added support. Does it makes sense to add this feature now?
In terms of API level changes, I imagine the file argument to tus.Upload would be expanded to allow ReadableStream in addition to File and Blob.
If the server doesn't allow deferred length uploads, we could either error when passed a ReadableStream or just read the whole stream into a Blob and uploader it. I don't have strong feeling either way.
I'd be happy to take a stab at implementing this if y'all think support should be added.
The text was updated successfully, but these errors were encountered:
Hi there, sorry for my late response. I personally have never used the new Streams API in browsers, so I am not sure what it actually can be used for. Furthermore, I am concerned about future changes of the Streams API. The MDN page (https://developer.mozilla.org/en-US/docs/Web/API/Streams_API#Browser_compatibility) says we should expect changes. Do you know what the status for the specification is?
That being said, I am not opposed to having support for them.
In terms of API level changes, I imagine the file argument to tus.Upload would be expanded to allow ReadableStream in addition to File and Blob.
I agree. That's similar to how ReadableStreams are accepted if tus-js-client is run inside Node.js. It might be helpful for you to look at how these are handled under the hood.
If the server doesn't allow deferred length uploads, we could either error when passed a ReadableStream or just read the whole stream into a Blob and uploader it. I don't have strong feeling either way.
In this case and that the user didn't specify the upload length in advance, the upload should not be read into a buffer. The user should do this explicitly to be aware of the required memory usage.
I'd be happy to take a stab at implementing this if y'all think support should be added.
In issue #59, @Acconut called out that it doesn't makes sense for tus-js-client to support the creation-defer-length extension until tusd supports it. However, since then, tusd has added support. Does it makes sense to add this feature now?
In terms of API level changes, I imagine the
file
argument totus.Upload
would be expanded to allowReadableStream
in addition toFile
andBlob
.If the server doesn't allow deferred length uploads, we could either error when passed a
ReadableStream
or just read the whole stream into aBlob
and uploader it. I don't have strong feeling either way.I'd be happy to take a stab at implementing this if y'all think support should be added.
The text was updated successfully, but these errors were encountered: