Although the thread is almost a year old, I haven't found any replies
to these questions, so I'm sharing what I've found:
I have a few questions and an idea.
Does calling send( file ) generate the appropriate Content-Type
request header with matching boundary?
No, it doesn't. I've filed
Thanks for taking the lead on this Arun!
Since we eventually need to show we've satisfied its [=the spec's]
relevant technical requirements [1], did the Web API WG do some
related requirements work? If yes, where can we find that work?
-Regards, Art Barstow
[1]
Garrett Smith wrote:
On Fri, Sep 5, 2008 at 12:28 PM, Arun Ranganathan [EMAIL PROTECTED] wrote:
All,
Hi Arun,
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
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
Just wanted to follow up with this.
How can we proceed with getting some file serialization implemented?
I would like to create some tests. Should there be async/sync, or just async?
I'm sure it's going to be a useful feature.
Jonas was also helping flesh out some ideas for Form
On Mon, Aug 11, 2008 at 9:04 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
Sorry, the and browser at the end was a typo. I meant to say, in the
browser. The reason synchronous access to the disk is a bad idea is
that
if the operation takes too long, a big file, a slow network home
directory,
On Aug 11, 2008, at 11:21 PM, Garrett Smith wrote:
The other problem is that setTimeout does not result in async
javascript
execution it merely delays the synchronous execution of a script.
I've just tried to upload a 1.1mb log file from my hard drive and had
no issue reading. Using
Just a few weeks ago (http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html
) I proposed a stripped down version of the File Upload spec (thinking
it defunct) that matched Mozilla's implementation sans the data
accessors. One reason for not including the data accessors
On Mon, Aug 11, 2008 at 7:18 PM, Sam Weinig [EMAIL PROTECTED] wrote:
Just a few weeks ago
(http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html) I
proposed a stripped down version of the File Upload spec (thinking it
defunct) that matched Mozilla's implementation sans the
On Aug 11, 2008, at 7:30 PM, Garrett Smith wrote:
On Mon, Aug 11, 2008 at 7:18 PM, Sam Weinig [EMAIL PROTECTED] wrote:
Just a few weeks ago
(http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html
) I
proposed a stripped down version of the File Upload spec (thinking it
Sorry, the and browser at the end was a typo. I meant to say,
in the
browser. The reason synchronous access to the disk is a bad idea
is that
if the operation takes too long, a big file, a slow network home
directory,
Then:
function readFile(file) {
// 1. Check the fileSize property.
Garrett Smith wrote:
The File object is useful for uploading files via XHR. It provides
functionality for data to be retrieved from a file submitted to a
formusing the input type file.
It is currently a Working Draft:
http://www.w3.org/TR/file-upload/
12 matches
Mail list logo
