W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 16 Oct 2008 20:46:32 -0700
Message-ID: <48F80A98.9010900@sicking.cc>
To: Maciej Stachowiak <mjs@apple.com>
CC: arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>

>>>> 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 of the things that Google propose?
>>> [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] 
>>> http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0387.html
>> Were you referring to [3] above? I didn't actually realize that Apple
>> was proposing that as a v1 for the FileUpload spec. Apologies for
>> that, it was certainly not intended to be ignored.
> Yes, [3] was our intended proposal for v1 of the file upload spec. I 
> don't recall hearing any objection to publishing that as v1.
> Arun did not ever respond to that email thread, and your only comment 
> was "This sounds like a great idea to me."

Nowhere in [3] did it mention that this was a proposal for a v1 of the 
FileUpload spec. In fact, it did not mention at all what to do with the 
proposal, i.e. publish as a Note, add to a new spec, add to an existing 
spec such as XHR Level 2, etc.

Hence the confusion on my part. My apologies.

>> I do agree that that API is good and should become part of the web
>> platform, however I'm not sure that it solves enough use cases that it
>> deserves a spec on its own. Basically it only provides a 'cleaner' API
>> for what you can already do by adding target="a-hidden-iframe" on a
>> <form> element and calling .submit().
> Not true. It lets you upload files with explicit in-page progress UI, 
> which form submission cannot do. It lets you perform the upload (and 
> show the feedback) from a different frame or window than where the user 
> chose the file. It lets you upload multiple files selected from a single 
> file control but one at a time and with separate progress feedback for 
> each.
> These are all specific requests that we have heard from Web developers, 
> who are more interested in these features than direct access to file 
> bytes without doing an upload.

We added the .files/File API as part of the effort to support offline 
apps. In such a case you need access to the data so that you can store 
it in localStorage, or you need to extend localStorage to be able to 
store File objects rather than just strings.

There are for sure very good use cases for both accessing data as well 
as sending it to the server using XHR.

>> I think at the very least we should provide the ability to get access
>> to the data from within javascript so that you don't have to upload
>> the data to the server and pull it back down again. Be that through
>> the mozilla API or the google Blob API (seems like most people are
>> pushing for the google Blob API so I suspect we'll land on something
>> like it). That I think is a much bigger enabler for web developers and
>> a higher priority for at least me to get specified.
> I don't like either the Mozilla API or the Google Blob API. I think it 
> will probably take some time to agree on a good API - I don't think the 
> union of everyone's proposals is a good way to do that. I think it will 
> take time to come to a consensus on the right API for direct access to 
> the file contents - it is a good idea, but there are divergent 
> approaches, all with their flaws.

I guess I'm fine with doing a v1 spec that just contains the parts in 
[3] as long as we don't hold off on a spec for accessing data at the 
same time, be that a FileUpload v2 spec or something completely separate.

That does seem like more work editor-wise though, so I'll leave that 
decision to the editor.

>> I'm less convinced that we need the FileDialog interface from Robin's
>> original spec as it's basically again just a "cleaner" API for
>> something that is already possible.
> Instead of "cleaner" I would say it arguably has more security risk, 
> since <input type="file"> binds things to an unforgable user action.

 From a UI point of view the FileDialog brings up the same UI, no? You 
still get the same filepicker when FileDialog.open is called. And you 
can similarly prevent an <input type="file"> from being rendered using a 
plethora of CSS tricks.

/ Jonas
Received on Friday, 17 October 2008 03:50:01 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC