W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2010

Re: Media Capture API restructured

From: Rich Tibbett <rich.tibbett@gmail.com>
Date: Wed, 7 Jul 2010 12:40:36 +0100
Message-ID: <AANLkTin4jbDRVz2VV_nNEF5AsDfndwNG8ZSLrI9wpLaW@mail.gmail.com>
To: Ilkka.Oksanen@nokia.com
Cc: public-device-apis@w3.org
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?
> 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?
> - Richard
[1] http://dev.w3.org/html5/html-device/

> On Wed, Jul 7, 2010 at 9:13 AM, <Ilkka.Oksanen@nokia.com> wrote:
>> Hi,
>> Based on the decision during the previous call, I have now split the Media
>> Capture spec into two:
>> Form Based Access: http://dev.w3.org/2009/dap/camera/Overview.html
>> Programmatic API: http://dev.w3.org/2009/dap/camera/Overview-API.html
>> Comments welcome. ViewFinder interface is postponed to level 2. Regarding
>> the form based access I ended to introduce a new boolean attribute called
>> 'capture' for <input type=file>. Current text in HTML5 defines exhaustive
>> list of accepted comma separated tokens for the accept attribute. I don't
>> think it's appropriate to extend that list blindly in a separate spec.
>> Related to this, I believe the question remains if the form based spec
>> should stay in its own document in the first place or should it be actually
>> merged to HTML5 spec. I guess it can be now seen as a simple HTML5
>> extension. I think we should at least check now that there are no blocking
>> issues with this kind of approach.
>>           -ilkka
Received on Wednesday, 7 July 2010 11:41:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:21 UTC