Re: [MSE] Summary of 'Appending URLs' thread

Hi Aaron,

Thanks for writing this up. My answers to your questions below …

On Jul 24, 2012, at 9:44 AM, Aaron Colwell wrote:

Hi,

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.

Agreed - goal 2 applies with any kind of appending mechanism.

I think goals 1 & 3 could be solved via special interactions with XHR or Blobs(Mark Watson's idea from a side email conversation).

Here are my questions for the group:

Do people agree with the goals I've outlined?

Yes.

If not, what should be changed?

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

I think so. appendUrl() implies a significant change in the functional split between JS and UA. We'd like to get more experience with the existing functional split (which puts more functionality on the JS side) before embedding more in the UA. But we'd also like to achieve the three goals above.


How do people want to proceed?
  - Should I start 3 new threads? (1 exploring append(XmlHttpRequest),  1 exploring append(Blob),

Those could be one thread, as there may be other similar options that should be rolled into the discussion as well.

and 1 for append rate control)
  - Should we have a call for proposals on how to accomplish these goals?

I think your email is exactly that ;-)

…Mark


Aaron