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

On Oct 15, 2008, at 11:54 PM, Jonas Sicking wrote:

> On Wed, Oct 15, 2008 at 10:57 PM, Arun Ranganathan  
> <arun@mozilla.com> wrote:
>>
>> 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 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."

> 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.

> 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'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.

Regards,
Maciej

Received on Friday, 17 October 2008 03:00:28 UTC