chaals et al.,
Yep. I am waiting for people to comment on whether they are happy to
roll up about 11 on Tuesday
I am happy enough with an 11a.m. start time; I suspect, however, that
our discussions will run over a bit, and thus, I think we ought to be
prepared for that.
-- A*
Doug Schepers, Charles McCathieNevile (Chairs), Members of the WG,
On behalf of Mozilla, I'd like to introduce the possibility of two new
work items for this group to consider. Neither of these is presented as
a fait accompli, although we would like to consider both of these for
inclusion
Maciej,
1. Worker Threads in Script.
Apple is interested in a worker API. The key issues for workers, in my
opinion, are security, messaging, and which of the normal APIs are
available. Right now, these things are covered in HTML5, so I think
that may be a better place to add a Worker
All,
At the recent F2F discussions in Redmond covering XMLHttpRequest (Level
2) and Access Control, the question of user involvement came up more
than once. This discussion raised issues about whether or not the user
should be informed by a user interface mechanism in the browser that a
All,
On behalf of Mozilla, I'd like to take over as editor of the FileUpload
spec., which was actually once assigned to me quite some time ago :)
Of course, I think that
form.getDataAsString();
form serialization is out of scope of this particular specification, but
I think other things
Sam,
I don't think we should include synchronous access to File data
provided by:
DOMString getDataAsText(in DOMString encoding) raises(FileException);
DOMString getDataAsBase64()
raises(FileException);
DOMString
Maciej,
My first question would be:
Why did you ignore Apple's proposal to start with a minimal common
interface (which most people seemed to like) and instead wrote a draft
that is the union of all things in Robin's original spec, all things
that Mozilla happened to implement, and a bunch
All,
Maceij wrote:
[1]
http://lists.w3.org/Archives/Member/member-webapps/2008OctDec/0010.html
[2]
http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0047.html
[3]
http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html
[4]
I'd like review on the most recent draft of the File API (renamed from
FileUpload API) [1]. There's been a great deal of interest in the
File API from different quarters[2], and I look forward to feedback on
how to represent file lists, file objects (and accessors), file
selection dialogs,
Timeless,
These are all sensible nits and I'll incorporate them.
-- A*
timeless wrote:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
Note, I expect all of my comments here to be of an editorial nature.
In the Abstract:
use of appropriate [DOM]DOM methods should return a
Robin,
- The indentation of your WebIDL snippets is a bit broken, which
makes them hard to read.
I've got this nit numerous times; I'm going to fix it.
- Do we want to keep FileList? I think we're all tired of those. I
know that the sequenceT section of WebIDL hasn't been written, but
Anne van Kesteren wrote:
I would prefer it if fileName and fileSize were simply named name and size
instead. It should be clear from the object what they mean.
OK.
I think it would be better if the FileError object was not modeled after the
DOMException interface. Making it consistent
Ian Hickson wrote:
On Thu, 18 Jun 2009, Arun Ranganathan wrote:
I think FileDialog is a bad idea. We already have UI for selecting
multiple files: input type=file multiple. (And soon with
DataTransfer.files we have a second one.) I would much rather wait
with FileDialog until it is very
Michael(tm) Smith wrote:
For those on this list who are not also on the www-tag list, this
is just a heads-up that there's an informal draft document --
titled W3C and APIS -- that's likely to be of some potential
interest to people following the WebApps WG work. It was written
by Ashok
Boris Zbarsky wrote:
Ian Hickson wrote:
Local display of images before uploading them requires being able to
take a File object and poke it into parts of the platform that
currently only take URLs. I suggest that the way we address this is
by adding an API to a File object that returns a URL
Robin Berjon wrote:
On Jun 19, 2009, at 10:16 , Anne van Kesteren wrote:
On Fri, 19 Jun 2009 01:01:41 +0200, Arun Ranganathan
a...@mozilla.com wrote:
Ian Hickson wrote:
I spoke with the developers of one of these Well-Known Web
Applications, and they didn't even _mention_ the styling
Arthur Barstow wrote:
Members of the Web Apps WG,
Below is an email from Henry Thompson (forwarded with his permission),
on behalf of the TAG [1], re the CORS spec [2].
Two things:
1. Please respond to at least this part of Henry's mail:
[[
It appeared to us that a number of significant
Doug Schepers wrote:
Hi, Nikunj-
I think Mike was overly blunt, but essentially correct in his
response, but I'd like to add a specific comment inline...
Nikunj R. Mehta wrote (on 6/24/09 8:13 PM):
On Jun 23, 2009, at 5:10 PM, Ian Hickson wrote:
The Web Storage specification is someone
Garrett,
Thanks for taking the time to review this.
Garrett Smith wrote:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
Why does the URI contain the date 2006?
It certainly is confusing, but the '2006' persists as an artifact of the
CVS repository that I'm using to work on
Aaron,
Thanks for updating the Gears documentation!
Ok, it's live now. You can check out the Blob.getBytes() method here:
http://code.google.com/apis/gears/api_blob.html
There appears to be general support for byte ranged FileData objects.
FileData (from which File inherits) will
Michael Nordman wrote:
http://code.google.com/apis/gears/api_blobbuilder.html
This I'm less sanguine about, since the immediately desired capability is
to work with existing system files.
The motivating usecase for this feature in Gears is to compose the body of a
POST in the
Michael Nordman wrote:
The BlobBuilder.append() method is central to the use-case I'm referring to.
builder.append(string data that comprises the multipart/form-data header);
builder.append(string data that comprises simple text part);
builder.append(string data that comprises the start of a
I have updated the draft of the File API, and welcome more review. Note
that it is no longer called FileUpload since this term has become
misleading.
In particular, here are some of the issues addressed (and some not):
Any reason you're using an XHTML file to edit this? Also, the
Garrett Smith wrote:
Please show the subsequent use cases you've studied and please do
publish your studies.
What I meant by use cases was this exchange:
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0371.html
Dmitry,
the spec lists a use case about a web app that needs to send file(s) to the
server programmatically. I happen to think lately about an E-mail app that
can send attachments. FileData and its splice() method are useful here. I
assume the XHR2 spec would get XHR.send(FileData) method.
Gregg Tavares wrote
The File API is meant to talk to your local file system. It isn't a
network download API, but it seems that's what you want :-). Perhaps I am
misunderstanding your question?
Sorry, I was told on the HTML5 list that this is where network downloads and
archive support
Garrett Smith wrote:
In glancing at some of the methods in FileAPI, I noticed some coding
errors.
There definitely were errors; thank you for catching them.
First, an overview explanation:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml#dfn-getAsDataURL
|... If the call is
Gregg Tavares wrote:
How about this?
Why make a new API for getting the contents of a file (local or otherwise)
when we already have one which is XHR?
What if FileList was just array of File objects where each File object is
just a URL in the format
filedata: uuid, filename
Then you can use
splice should synchronously return a new FileData object. No need for
asynchronous callback since no IO occurs.
Done, though I used Anne's suggestion to make it an attribute.
Whoops, no I didn't mean Anne's suggestion for slice -- I meant it for
getAsURL.
Also the current draft is:
Adam de Boor wrote:
this is a minor point, but I'm finding the name of the splice method to be
odd. To me splice means to join, and slice would seem a more appropriate
name. The Array object has both splice and slice, and the former is used for
removing and inserting data and modifies the array
Latest draft is:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Anne van Kesteren wrote:
Thanks for the update to the draft! Below some feedback:
In the table of contents the link to the filedata URL scheme is broken.
Fixed.
The Web IDL syntax needs to be updated. E.g.
Michael Nordman wrote:
The draft says a new UUID should be 'coined' for each method invocation.
(Why is that?) Given the coinage of a new url on each access, accessing it
thru an attribute feels a little odd.
This should have been an editor's note, and not a part of the spec.
text. The
' and the 'FileUpload' are historical leftovers :-)
I hope to make headway on these issues by next week.
-- A*
[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html
[2] http://www.ietf.org/rfc/rfc4122.txt
Dan Connolly wrote:
On Wed, 2009-08-12 at 13:55 -0700, Arun
Anne van Kesteren wrote:
On Wed, 12 Aug 2009 17:13:57 +0200, Arun Ranganathan a...@mozilla.com wrote:
Latest draft is:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Thanks Arun!
Anne van Kesteren wrote:
I have not received any feedback on my comments
Michael Nordman wrote:
Currently we have File and FileData, where a File object ISA FileData
object... completion is delivered via readXXX method completion callbacks.
It would be easy to add progress callbacks to those readXXX methods.
I think Garrets point about two different corners of the
Nikunj R. Mehta wrote:
On Aug 12, 2009, at 7:29 AM, Arun Ranganathan wrote:
Gregg Tavares wrote:
How about this?
Why make a new API for getting the contents of a file (local or
otherwise)
when we already have one which is XHR?
What if FileList was just array of File objects where each
Nikunj R. Mehta wrote:
On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote:
What's the use-case for getAsBase64?
I have another use case for this. The Atom Publishing protocol per RFC
5023 [1] accepts inline binary data represented in base 64 encoding.
In order to submit binary inline
Aaron Boodman wrote:
On Mon, Aug 17, 2009 at 2:45 AM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 8/17/09 12:33 AM, Michael Nordman wrote:
Strictly speaking, I think the seperate 'Reader' class makes for a more
correct API. The two corners above would not conflict since each would
Jonas Sicking wrote:
There's lots of formats used on the web, I don't think it makes sense
to add file-getters for all of them. JSON has gotten a lot of
attention lately, does this mean we should add a getter that return a
js-style escaped string?
I don't really feel very strongly about
Michael,
I'd like to distinguish between file:// and filedata: which is what the
current FileAPI proposes.
While file:// behavior is undefined and pretty vague across user agents,
filedata: is spec'd to be used within web applications, has a lifetime,
an origin policy, and does return a
Michael A. Puls II wrote:
Using filedata: and the FileAPI instead of file: with xhr, seems like
it'd work. However, how do you get a fileData object without input
type=file?
Whereas file:// gives you (sometimes constrained) access to the file
system, including directories, etc., filedata:
Nikunj R. Mehta wrote:
Hi Arun,
Thanks for pulling together all those references and sharing your
research conclusions in such painstaking details. I really appreciate
your hard work. I was particularly interested in seeing whether you
had included the Java I/O API design in your work.
Anne van Kesteren wrote:
On Sat, 22 Aug 2009 11:30:18 +0200, Simon Pieters sim...@opera.com
wrote:
On Wed, 12 Aug 2009 17:22:53 +0200, Arun Ranganathan
a...@mozilla.com wrote:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Maybe the attribute should be called URL
Ian Fette (イアンフェッティ) wrote:
I would like to make another plug for
http://dev.w3.org/2006/webapi/fileio/fileIO.htm
This had the notion of writing files, file streams, directories, and
being able to integrate into the host filesystem. All of these are
important for reasons I outlined in
Nikunj,
The File API is everyone's favorite API for feature requests as well as
programming style discussions :)
interface InputStream {
read(in DataHandler, [optional in] long long offset, [optional in]
long long length);
abort();
attribute Function onerror;
}
There is lots that
Arun wrote:
There is lots that is attractive about InputStream, and I think that
it can be used in other specifications, especially when discussing
Camera APIs, streaming from web apps (conferencing) etc. I also like
the idea of DataHandler. When we define a byte primitive, it can be
used
Darin Fisher wrote:
FileData::slice appears to be spec'd like so:
FileData slice(in long long offset, in long long length); // throws
FileException
This suggests that it may throw a file exception. I'm wondering if that is
a requirement? It seems that the rest of the methods are designed to
Julian Reschke wrote:
Hi,
here are a few comments after a superficial read of
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html:
- wouldn't FileStatus be a better name than FileError, given that it
can also contain a success code?
I'm in the process of updating the spec. to
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3.org/2006/webapi/FileAPI/
These changes constitute a substantial reworking of the original API
along the lines of the Alternative File API proposal [1]. There are
also some additional changes that are worth
Jonas Sicking wrote:
On Mon, Oct 26, 2009 at 5:24 AM, Arun Ranganathan a...@mozilla.com wrote:
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3.org/2006/webapi/FileAPI/
A few comments:
* loadend should fire after load/error/abort.
Currently
Ian Hickson wrote:
On Tue, 27 Oct 2009, Jonas Sicking wrote:
On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 Oct 2009, Jonas Sicking wrote:
All we're saying is that urn:uuid represents a specific chunk of data
with a specific mimetype. This seems
Dominique Hazael-Massieux wrote:
Le lundi 26 octobre 2009 à 05:24 -0700, Arun Ranganathan a écrit :
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3.org/2006/webapi/FileAPI/
The WebIDL checker identifies a couple of simple bugs in the draft:
http
Jonas,
When loadend was removed from media elements [2] I wished to determine
whether it was event overkill to also fire at successful reads. Sounds
like you want it back for successful reads as well?
But the reason why loadend *and load* was removed from video do not
apply here. The
Adrian Bateman wrote:
On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman
adria...@microsoft.com wrote:
On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
But like Arun, I suspect that this feature is the most
Dominique Hazael-Massieux wrote:
Le mardi 03 novembre 2009 à 21:27 -0800, Arthur Barstow a écrit :
This is a Call for Consensus (CfC) to publish the First Public
Working Draft (FPWD) of the File API spec, latest Editor's Draft at:
http://dev.w3.org/2006/webapi/FileAPI/
My
Dominique Hazael-Massieux wrote:
Le mardi 03 novembre 2009 à 21:27 -0800, Arthur Barstow a écrit :
This is a Call for Consensus (CfC) to publish the First Public
Working Draft (FPWD) of the File API spec, latest Editor's Draft at:
http://dev.w3.org/2006/webapi/FileAPI/
My
Anne van Kesteren wrote:
This should be a bit more exact as to how the mediaType is returned. I
would prefer ASCII-lowercase.
Done.
Returning application/octet-stream rather than null also seems
better if the type is not known. That way you do not have to type
check. Other parts of the
Anne van Kesteren wrote:
It might make sense to rename INITIAL to EMPTY for consistency with
HTMLMediaElement. Instead of LOADING READING might be better though I
care less about that one.
Done, but I'll point out that this isn't *exactly* consistent with
HTMLMediaElement. I agree that
Maciej Stachowiak wrote:
On Nov 10, 2009, at 5:29 PM, Anne van Kesteren wrote:
The name of the file as a UTF8-encoded string. A DOMString is not
UTF-8-encoded. I think this should just say Returns the filename.
It is not more complicated than that as far as I can tell.
There are some
Greetings Dom!
Dominique Hazael-Massieux wrote:
I alluded to this during the joint F2F meeting between WebApps and DAP
last week, but thought I would make the proposal more formally: given
that the current “File API” [1] really defines a FileReader interface,
and given that DAP is supposed to
Greetings Paul :)
At Osmosoft, we took some time to collectively read the File API
Editor's Working Draft 28 October 2009:
Thank you very much for taking the time, and sending your review
comments. My responses below:
Overall we welcome the formalization of access to local files,
Marcin Hanclik wrote:
What if the @type is derived from unverified metadata and the UA relies on the
underlying OS (assuming the file is local) ?
Does it mean that the UAs should always sniff to ensure that the @type is
correct?
Should we apply the procedure similar to the one from PC
Julian Reschke wrote:
Arun Ranganathan wrote:
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3.org/2006/webapi/FileAPI/
...
4. A suggestion to *not* have a separate scheme (filedata:) in lieu
of urn:uuid:uuid[2] has been the basis of a rewrite
Greetings Marcin,
Thanks for the thoughtful feedback. My comments below:
In my opinion some part of the design from ProgressEvents is taken over in
FileReader API too directly.
Specifically the event names are the same as within the ProgressEvents, but I
assume they should be adjusted to
Eric,
I recall you saying at TPAC that you wanted to keep the Blob
interface as small as possible, since it seemed likely to get used in
a lot of places. I think that's an excellent goal, but of course,
having said that, I am immediately going to suggest that you add
something to it.
Marcin Hanclik wrote:
Hi Anne,
XHR still is used also for data retrieval, so it is a kind of border case and I can live
with load there :) .
Using load for writing to a file will mean that we are stuck with the legacy stuff.
load and write pull semantically in the opposite directions, IMHO.
Peter O. Ussuri wrote:
Hello!
This is in reply to Eric Uhrhane's message, and other discussions [1]
Various File API use cases discussed in this mailing list are designed to
illustrate some kind of expansion of existing browser capabilities, with
ensuing discussion of potential new security
Today, the WebGL WG at Khronos [1] released a public draft of the WebGL
specification [2], and we really welcome (and need) wide review. Along
with Mozilla folks, the WebGL WG has representatives from Opera, Google,
and Apple, and nightly builds of Firefox, Chromium, and Safari have
support
Charles McCathieNevile wrote:
On Mon, 07 Dec 2009 16:46:12 -0800, Arthur Barstow
art.bars...@nokia.com wrote:
This is a Call for Consensus (CfC) to publish a Last Call Working
Draft of the following specs:
1. Server-Sent Events
http://dev.w3.org/html5/eventsource/
2. Web SQL Database
Greetings WebApps WG,
I have updated the editor's draft of the File API to reflect changes
that have been in discussion.
http://dev.w3.org/2006/webapi/FileAPI
Notably:
1. Blobs now allow further binary data operations by exposing an
ArrayBuffer property that represents the Blob.
On 5/13/10 7:37 AM, David Levin wrote:
On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathana...@mozilla.com wrote:
Greetings WebApps WG,
I have updated the editor's draft of the File API to reflect changes that
have been in discussion.
http://dev.w3.org/2006/webapi/FileAPI
Notably:
1.
On 5/13/10 7:37 AM, David Levin wrote:
On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathana...@mozilla.com wrote:
Greetings WebApps WG,
I have updated the editor's draft of the File API to reflect changes that
have been in discussion.
http://dev.w3.org/2006/webapi/FileAPI
Notably:
1.
On 5/13/10 1:50 PM, J Ross Nicoll wrote:
On 13 May 2010, at 13:27, Arun Ranganathan wrote:
Greetings WebApps WG,
I have updated the editor's draft of the File API to reflect changes that have
been in discussion.
http://dev.w3.org/2006/webapi/FileAPI
Notably:
1. Blobs now allow further
On 5/13/10 9:32 PM, Darin Fisher wrote:
Glad to hear that you didn't intend sync access :-)
I have thoughts on Blob and how it should behave (and about the
inheritance relationship between Blob and File), which is why I left the
unfortunate error in the editor's draft for now (commented
On 5/18/10 2:35 PM, Eric Uhrhane wrote:
On Mon, May 17, 2010 at 3:37 PM, Dmitry Titovdim...@chromium.org wrote:
I have couple of questions, mostly clarifications I think:
1. FileReader takes Blob but there are multiple hints that the blob should
be actually a 'file'. As we see Blob concept
Robin,
ArrayBuffers, and affiliated Typed Array views of data, are specified in a
working draft as a part of the WebGL work [1]. This work has been proposed to ECMA's
TC-39 WG as well. We intend to implement some of this in the Firefox 4 timeframe, and
have reason to believe other browsers
On 6/2/10 3:42 PM, Eric Uhrhane wrote:
Arun:
In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods, still takes a File rather than a Blob. Is
that just an oversight, or is that an intentional restriction?
That's intentional; readAsDataURL was cited
On 6/2/10 3:48 PM, Eric Uhrhane wrote:
Sure, why not? Why would this be limited to File objects?
A File is supposed to refer to an actual file on the local hard drive.
A Blob is a big bunch of data that you might want to do something
with. There's nothing special about a File when it comes
On 6/2/10 5:06 PM, Jian Li wrote:
Hi, Arun,
I have one question regarding the scheme for Blob.url. The latest spec says
that The proposed URL scheme is filedata:. Mozilla already ships with
moz-filedata:. Since the URL is now part of the Blob and it could be used
to refer to both file data blob
On 6/3/10 4:13 AM, Robin Berjon wrote:
On Jun 2, 2010, at 23:02 , Jonas Sicking wrote:
I don't know who makes these decisions, but I'd imagine the editor
holds a certain amount of sway.
Decisions of what is in scope for a WG are made by the members (i.e. you) when
a WG is created.
On 6/15/10 1:15 PM, SULLIVAN, BRYAN L (ATTCINW) wrote:
We would not be in favor of this transfer. We believe this API needs to
be developed in the DAP group, as our vision for its functionality was
driven by the input from BONDI and in general as a *device* API (as
compared to an abstracted API
On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote:
Arun,
The basic concern I have is with the notion of browsers as the only
Web context and use-case that matters. The browser-based model for API
integration view (as I understand your position) is that the user must
be actively involved in
Bryan,
On 6/15/10 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote:
5) do the above programmatically in Javascript (not dependent just upon
user selection of an input element and interaction with a file selector)
6) provide security for this using the policy-framework approach as
being defined for
Hi David,
Thanks for your questions.
On 6/16/10 2:16 AM, David Rogers wrote:
The question of where you are represented and your ability to
participate cuts both ways - the same is true for us. I think if the
browser vendors want their products really to be seen as compatible
with
On 6/16/10 12:59 PM, David Rogers wrote:
[DAVID] I was actually referring to:
http://dev.w3.org/2009/dap/privacy-reqs/
(As mentioned in previous correspondence, I think securing an API and
privacy can be decoupled, but both are very relevant topics).
I've read that document and think that
On 6/22/10 8:44 AM, Adrian Bateman wrote:
On Friday, June 11, 2010 11:18 AM, Jonas Sicking wrote:
On Fri, Jun 11, 2010 at 11:11 AM, Jonas Sickingjo...@sicking.cc wrote:
On Fri, Jun 11, 2010 at 9:09 AM, Adrian Batemanadria...@microsoft.com
It's not clear to me the benefit of
On 6/23/10 9:50 AM, Jian Li wrote:
I think encoding the security origin in the URL allows the UAs to do
the security origin check in place, without routing through other
authority to get the origin information that might cause the check
taking long time to finish.
If we worry about showing
On 6/28/10 3:41 PM, Alexey Proskuryakov wrote:
28.06.2010, в 15:37, Adam Barth написал(а):
I believe Alexey Proskuryakov has strong feelings on this topic.
I e-mailed public-webapps not long ago, but that seems to have gone
unnoticed,
On 6/28/10 6:58 PM, Eric Uhrhane wrote:
The discussion at [1] got tangled up with the debate of .URL vs. .url,
so I'm starting a new thread to pick back up the original topic: how
do we save binary data from XMLHttpRequest? Here's my proposal [built
mainly from the good ideas other folks posted
On 6/29/10 11:09 AM, Julian Reschke wrote:
Hi Arun,
On 28.06.2010 23:20, Arun Ranganathan wrote:
...
2. I've updated the URL scheme for Blobs using an ABNF that calls for an
opaque string which is a term I define in the specification. There was
much discussion about this aspect of the File API
Jian,
On 8/28/10 8:59 PM, Jian Li wrote:
Adding explicit methods to window and WorkerGlobalScope seems to be a
better solution that solves potential problems we currently have with
blob.url. Given that, we're going to experiment the proposed new APIs
in the WebKit implementation, That is,
OK, thank you Darin :) This alleviates the naming tension.
FileReader, FileException, and FileError it is, then.
(Eliminating Blob from the inheritance hierarchy causes the problems Darin
mentions below).
On Mon, Aug 30, 2010 at 10:52 PM, Anne van Kesteren ann...@opera.com wrote:
- Original Message -
On Mon, 6 Sep 2010, Nathan wrote:
Just noticed that File API specifies NOT_READABLE_ERR as code 24,
whereas 24 is already used for DATA_CLONE_ERR
http://dev.w3.org/html5/spec/common-dom-interfaces.html#data_clone_err
Not sure if this is an issue or not,
On Tue, 7 Sep 2010, Arun Ranganathan wrote:
It *does* seems sensible to use DOMException instead of
FileException in
the synchronous case (on WebWorkers). But in the asynchronous case,
DOMError seems a bit janky
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#ERROR-Interfaces
- Original Message -
On Wed, Sep 8, 2010 at 12:43 AM, Anne van Kesteren ann...@opera.com
wrote:
That works for me too, but then please use internally consistent
numbering
rather than some codes matching DOMException and the new codes not
matching
DOMException as that is just
On 9/7/10 10:08 PM, Darin Fisher wrote:
On Tue, Sep 7, 2010 at 5:23 PM, Kenneth Russell k...@google.com
mailto:k...@google.com wrote:
On Tue, Sep 7, 2010 at 4:19 PM, Nathan nat...@webr3.org
mailto:nat...@webr3.org wrote:
Jian Li wrote:
Hi,
Several specs, like
On 9/28/10 4:37 PM, Jeremy Orlow wrote:
I'm OK with any time slot.
This year, I am also not sure whether I'll attend, but I'd like to
request File API moved to Tuesday, particularly to a dial-in friendly
time. It seems likely that I'll dial-in and participate via IRC from
the East Coast
WebApps WG,
There have been some updates to the File API.
http://dev.w3.org/2006/webapi/FileAPI/
Notable changes are:
1. Exception codes are no longer harnessed to DOMException's exception
codes, per discussion on this listserv.
2. Metadata attributes creationDate and lastModifiedDate
On 10/12/10 2:12 PM, Eric Uhrhane wrote:
Arun:
On Tue, Oct 12, 2010 at 10:46 AM, Arun Ranganathana...@mozilla.com wrote:
WebApps WG,
There have been some updates to the File API.
http://dev.w3.org/2006/webapi/FileAPI/
Notable changes are:
1. Exception codes are no longer harnessed to
On 10/18/10 10:14 AM, Anne van Kesteren wrote:
On Mon, 18 Oct 2010 16:03:30 +0200, Arthur Barstow
art.bars...@nokia.com wrote:
Arun and Jonas would like to publish a new Working Draft of the
File API spec and this is Call for Consensus to do so:
http://dev.w3.org/2006/webapi/FileAPI/
1 - 100 of 309 matches
Mail list logo
