streams as a replacement for progress events... what about upload progress?

yutakahirano / fetch-with-streams

Fetch API integrated with Streams.

66 stars 8 forks source link

streams as a replacement for progress events... what about upload progress? #24

Closed caitp closed 6 years ago

caitp commented 9 years ago

It's clear that you could consume a streaming response body at chunk intervals, as a replacement for progress events.

But this doesn't exactly help if you wanted to track the progress of an upload. Just wondering if anyone has had any ideas about that.

domenic commented 9 years ago

The plan is to have uploads be represented by a writable stream that you write to. Then you know the progress: it's the number of bytes you've written divided by the total number of bytes you plan to write.

yutakahirano commented 7 years ago

Imagine a user has a Blob blob. If the user wants to make a fetch with uploading blob, is it desirable to create a ReadableStream from blob just for receiving progress events?

Chrome is able to send a Blob efficiently but creating a ReadableStream from the Blob and sending the ReadableStream manually will disable the optimization. Hence I would like to have a means to receive progress events while sending a Blob directly.

jakearchibald commented 7 years ago

F2F:

We could make it easy to turn blobs into "bounded streams", that know their total size, and provide a progress callback - but this doesn't work for .json.
An argument to bodyinit, fetch(url, {progressCallback})
blob.toStream(), formData.toStream() etc etc
Observables maybe, but that needs to go through tc39

wanderview commented 7 years ago

Not sure if this is settled or not, but wanted to throw my perspective in.

As an implementer I'd really like progress to be a separate API from the body stream. In order to implement streaming without a perf penalty we need to do some amount of internal buffering. In contrast, progress events currently attempt to provide status based on bytes that are read/write at the OS-level syscalls. Obviously this does not play well with any internal buffering.

So in my mind we must pick one of these:

Separate progress API from streams
Stream-based progress understanding its measuring progress of internal buffering
Stream-based progress measuring OS-level syscalls, but with slow performance

rajendrarathore commented 7 years ago

Yes much needed feature for trace the upload progress.

I hope to see that feature in future release.

MartinMuzatko commented 6 years ago

Has there been any updates in a year? Working examples?

yutakahirano commented 6 years ago

I haven't worked on this issue. Is https://github.com/whatwg/fetch/issues/65 related?

annevk commented 6 years ago

I think we're still waiting for experimentation on top of streams before figuring out exactly what to expose.