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

On Oct 16, 2008, at 8:46 PM, Jonas Sicking wrote:

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

I had a vague recollection that the Chairs suggested FileUpload was  
the right track, but I could be wrong. Anyway, sorry for not being  
clear. I would really like it if that set of functionality could be  
published as a baseline v1 of FileUpload, for lack of a better place.

> 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 so too. I'm just saying, the XHR-only bit is simpler and  
closer to consensus.

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

I think it could be FileUpload v2. I think we should start it with  
some strawman proposals and trying to decide some key issues. I will  
post on what I don't like about the Mozilla and Blob models for file I/ 
O.

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

I bet Sam would be willing to help edit a pared down v1 spec if it  
would help.

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

But it does require an unforgeable user click to bring it up, so you  
can't spam it or make it pop up at carefully controlled times. Might  
not be a huge risk but I think the theoretical benefits are not worth  
it.

Regards,
Maciej

Received on Friday, 17 October 2008 04:49:42 UTC