- From: Andrei Popescu <andreip@google.com>
- Date: Wed, 7 Jul 2010 13:24:25 +0100
- To: Rich Tibbett <rich.tibbett@gmail.com>
- Cc: Ilkka.Oksanen@nokia.com, public-device-apis@w3.org
- Message-ID: <AANLkTimr0XsH8vJN-euKWLRpJbG8-HCaZmjsjyhUnRgn@mail.gmail.com>
Hi, On Wed, Jul 7, 2010 at 12:38 PM, Rich Tibbett <rich.tibbett@gmail.com>wrote: > Thanks for the updates! I can appreciate how much work goes in to this ;-) > > There seems a subtle demarkation should be made between the <input > type="file" accept="audio/*"> approach defined in this spec and proposed > usage of a <device type="media"> element. IMO, both elements would have > similar but subtle differences in their intended usage. > > It seems the <input> based capture model is a method for a user to create > an on-demand image/audio/video 'file' that can then be shared *in its > entirety* with a webapp at the point it has been fully captured. That works > because the input element is a form-based control and on form submit, the > user's video will be uploaded as if it were a regular file. I expect this is > the intended usage? > > Yes, that's one type of usage. The other is by getting the File object via HTMLInputElement::files and using that with the FileReader, etc. > Streaming media on the other hand doesn't, and probably shouldn't, end up > in a form-based file element because streaming media does not need to be > integrated with web forms. The data in a streaming session is bursty and > timely and typically has no longevity beyond the current streaming event. > That doesn't fit in with an <input> element which has a one-time onsubmit > and has longevity by submitting all stream data to the web server when that > may not necessarily be required. The typical use case for media streaming > would be obtain stream data, render/send the stream data and then either > save or discard the used stream data, much like the process is described in > the HTML Device draft [1]. > > Maybe there is potential to separate the subtleties of the pre-captured > stream file vs. the streaming media stream use cases with the <input> and > <device> elements respectively? > > Hmm, the current form-based approach draft doesn't mention streaming in any way. For clarity, maybe it should have a paragraph pointing to the html5 device spec, saying that streaming is handled there? Thanks, Andrei
Received on Wednesday, 7 July 2010 12:24:55 UTC