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

Re: Media Capture API restructured

From: Ilkka Oksanen <Ilkka.Oksanen@nokia.com>
Date: Fri, 09 Jul 2010 14:57:51 +0300
Message-ID: <4C370EBF.5000707@nokia.com>
To: ext Andrei Popescu <andreip@google.com>
CC: Rich Tibbett <rich.tibbett@gmail.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
On 08.07.10 15:49, ext Andrei Popescu wrote:
>  Hi,
>
>  On Wed, Jul 7, 2010 at 4:28 PM, Ilkka Oksanen
>  <Ilkka.Oksanen@nokia.com> wrote:
> > On 07.07.10 17:13, ext Andrei Popescu wrote:
> >>
> >> Also, could MediaArray be renamed to MediaList in line with the
> >> File API spec?
> >>
> >>
> >> Sounds fine.
> >>
> >
> > I can change this.
> >

MediaArray is now renamed to MediaList in CVS.

> >> As mentioned before, that's the approach we took in Android
> >> (except that the source can be camcorder / camera / microphone,
> >> rather than capture). It's easy to use and easy to implement.
> >
> > Introducing new attribute is a little bit cleaner solution as long
> > as input based capturing is a separate document I think.
>
>  Why is cleaner?
>

http://dev.w3.org/html5/spec/Overview.html#file-upload-state:

[[  If specified, the [accept] attribute must consist of a set of 
comma-separated tokens, each of which must be an ASCII case-insensitive 
match for one of the following:

The string audio/*
Indicates that sound files are accepted.
The string video/*
Indicates that video files are accepted.
The string image/*
Indicates that image files are accepted.
A valid MIME type with no parameters
Indicates that files of the specified type are accepted.

]]

For me "one of the following" hints that the list is exhaustive and that 
there are no separate specifications that extend it. In any case this is 
quite minor issue. Let's first check if the whole form based capturing 
document can be merged to HTML5 spec.

> >
> > Andrei and others, can you describe how you plan the source
> > parameter to work in practice in your implementation? Is it still
> > possible to select normal files if it exists? And vice versa, what
> > if "video/*" or "source=camera" is missing, is it then possible for
> > the user to capture video or audio?
> >
> > My thinking has been that both selecting files and capturing
> > content should be possible in every case. Source parameter or
> > attribute just hints in what mode the file picker should be
> > initially be.
> >
>
>  Are you thinking that this affects the choice of "capture attribute"
>  vs "source param"? I am not sure I see how...It sounds more like an
>  implementation issue to me.
>

Thanks for the detailed explanation. I think parts of it can be added to 
the specification as informative text about implementation alternatives. 
No impact on parameter vs. attribute question.

           -ilkka
Received on Friday, 9 July 2010 11:58:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:11 GMT