W3C home > Mailing lists > Public > public-html-media@w3.org > July 2012

[MSE] Summary of 'Appending URLs' thread

From: Aaron Colwell <acolwell@google.com>
Date: Tue, 24 Jul 2012 09:44:30 -0700
Message-ID: <CAA0c1bC15son0e_H5h3QZ=rSjqNvU+HvH_etySpL+OHBzbTqCQ@mail.gmail.com>
To: "<public-html-media@w3.org>" <public-html-media@w3.org>

I had an action item from the last MSE call to summarize the "Appending
URLs" thread.

Here goes:

1. There appears to be general agreement that this is useful. (MarkW,
Duncan, Yang)
2. Discussed what should be in appenddone event
  - bytes transferred, transfer duration, and http status code should be
included. (Duncan, MarkW)
  - Reason/error string is not necessary (Duncan, yang)
3. Discussed what should be in appenderror event
  - bytes transferred, http status code (yang)
4. A progress event should be implemented to allow monitoring during the
transfer. (MarkW, Duncan)
5. NETWORK_IDLE & NETWORK_LOADING networkStates proposed to signal when the
UA starts/stops transferring data (Duncan)
6. Metrics for monitoring transfers should be or similar to the Web
Performane Resource Timing work. (MarkW, StevenR)
7. Brief discussion about parallel connections & concurrent transfers. (
MarkW, StevenR)
  - Parallel transfers are allowed, but no assumptions should be made about
the order or concurrency of the transfers.

While reading the emails again I kept hearing a voice in my head saying,
"like XHR" as people would make their various points. This is making me
think we should take a step back and figure out a way to use XHR instead of
defining a mechanism similar to it. When I initially proposed the appendUrl()
I was hoping it would accomplish these three main goals:

1. Prevent media data from being surfaced into the JS layer when no
modifications are necessary.
2. Provide a mechanism for the SourceBuffer to control the append rate so
it can avoid memory overflow in mobile devices.
3. Give the SourceBuffer access to media data as it is being received
instead of waiting until the whole transfer is complete.

I still believe these goals are important, but I'm not sure they should all
be solved with a single solution. I'm starting to believe that goal 2 needs
a distinct mechanism especially if we decide to have both URL based &
Uint8Array based appending methods. I think goals 1 & 3 could be solved via
special interactions with XHR or Blobs(Mark Watson's idea from a side email

Here are my questions for the group:

Do people agree with the goals I've outlined? If not, what should be

Should we drop appendUrl() in favor of an alternate approach?

How do people want to proceed?
  - Should I start 3 new threads? (1 exploring append(XmlHttpRequest),  1
exploring append(Blob), and 1 for append rate control)
  - Should we have a call for proposals on how to accomplish these goals?

Received on Tuesday, 24 July 2012 16:44:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:56 UTC