HTML Media Capture draft from Device APIs and Policy Working Group
Hello WebApps WG, The Device APIs and Policy Working Group has published a new draft called HTML Media Capture on which we think we'll need to coordinate with your group: http://www.w3.org/TR/2010/WD-html-media-capture-20100720/ That document defines a mechanism to bind an input type=file with a set of well-defined accept attribute values, completed by a mime type parameter (capture), with an extended file picker (that integrates access to on-device microphones, cameras and camcorder) and resulting in a MediaFile object that extends the File object from the FileAPI. Feedback from the WebApps Working Group on our proposed extension to the File interface (in the MediaFile interface) would be very much welcomed. Let me know if any additional details would be useful, Dom, on behalf of the Device APIs and Policy Working Group
[Bug 10211] New: Remove the no host-specific component requirement for targetOrigin, see implementor discussion in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027136.html and su
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10211 Summary: Remove the no host-specific component requirement for targetOrigin, see implementor discussion in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/20 10-July/027136.html and subsequent messages Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#pos ting-messages OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Messaging (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#posting-messages Comment: Remove the no host-specific component requirement for targetOrigin, see implementor discussion in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027136.html and subsequent messages Posted from: 84.208.127.109 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10213] The definition of absolute url makes https:foo not an absolute url, since its behavior depends on whether the base is https: or not. Is that desired? In particular, using this defini
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10213 Simon Pieters sim...@opera.com changed: What|Removed |Added CC||public-webapps@w3.org Component|HTML5 spec (editor: Ian |WebSocket API (editor: Ian |Hickson)|Hickson) Product|HTML WG |WebAppsWG QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org --- Comment #1 from Simon Pieters sim...@opera.com 2010-07-20 21:34:35 --- Changing component so Hixie sees this while working on websockets. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[CORS] What constitutes a network error?
Hi All, There are a lot of algorithms in the CORS spec that contains steps like: If there is a network error do X However I haven't been able to find a clear definition of what counts as a network error. Does this include successful HTTP requests that return 4xx or 5xx status codes? Or just errors in the lower level of the stack, such as aborted TCP connections? It would be good to have this clearly defined, preferrably with a link in all the places where it is used as a condition in an algorithm. / Jonas
Re: New draft of FileSystem API posted
Hi Eric,
Thanks for brushing up the draft.
We had some internal discussion about the API details and came up with a
question regarding is{File,Directory} attributes of Entry interface.
It seems like user agent needs to be able to tell if a given entry is file
or directory synchronously (or from its cache), but we wonder what should
happen if the underlying file object is changed later. For example, we may
have a situation like this:
1. a user code gets (or creates) a file entry.
2. another flow of the code (or another code in the same origin) removes the
same entry and creates a *directory* at the same path.
3. the original code refers isFile attribute of the entry. -- should it be
true or false?
If an Entry is just a reference (i.e. a pathname) of a system file entity,
it would look natural that it is resolved at run-time thus returns false in
the above case. But if so we'll have two problems: 1) we'll need to make
synchronous stat calls to get the attribute values, and 2) as we have
different interfaces for file and directory, we may end up with having
invalid FileEntry objects for directories - or vice versa.
Would it be possible to have a single unified interface for file and
directory and let scripts figure out the info at runtime (e.g. in each
asynchronous filesystem operation)?
On Wed, Jul 7, 2010 at 6:50 PM, Eric Uhrhane er...@google.com wrote:
I've posted a new draft of File API: Directories and System [1]. In
this draft I've rolled in quite a bit of feedback that I received
since first posting it on DAP--many apologies for the delay. This is
the first draft produced since we agreed to move this spec from DAP to
WebApps; I hope those of you who have time will give it a look and let
me know what you think.
In general I've tried to address any comment I was sent and had not
already addressed via email. The few that didn't make it in, I've
responded to below.
My thanks to Robin Berjon and Mike Clement for all their feedback.
Robin:
- data stored there by the application should not be deleted by the
UA without user intervention, UA should require permission from the
user, The application may of course delete it at will - these
sound like real conformance statements, therefore SHOULD, SHOULD NOT,
and MAY.
Those are in a non-normative section; is that language still appropriate
there?
Robin:
[discussion about speccing the URI format]
Left as an open issue.
Mike:
[discussion about multiple sandboxes per origin]
I think that would be very easy and clean to add later if desired, and
in the mean time, one can use subdirectories.
Mike:
getFile/getDirectory are a bit overloaded. How about including
methods like exists(), createFile() and createDirectory()? Though
these methods are easily implemented in terms of getFile/getDirectory,
I always prefer more direct API methods that help make the code easier
to understand. I expect, though, that you are attempting to be a low
level as possible here.
As Robin pointed out, adding extra round-trips will slow things down.
Also, it can encourage race conditions. These are easy for libraries
to implement via wrappers.
Mike:
[request for creation time in getMetadata]
It may be hard to support reliably cross-platform [2].
Robin:
[specifying a single locale everywhere]
I don't think that'll make folks very happy if it's not their locale.
If I e.g. try to force my locale on Turkish Windows users, they're
going to see some interesting errors trying to share files with apps
outside the browser, or for that matter even saving certain groups of
files from inside the browser.
Eric
[1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
[2] http://en.wikipedia.org/wiki/MAC_times
