Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec
On Oct 16, 2008, at 8:02 PM, Maciej Stachowiak wrote: On Oct 15, 2008, at 10:57 PM, Arun Ranganathan 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? FWIW, the Berjon spec. actually matches implementation in Mozilla, modulo a few differences, which I suppose the union reveals. And I *certainly* did not mean to willfully ignore input from anybody. I apologize if this is the impression my current draft gives, and hope to fix that very soon. But, looking back on correspondence from you, I find one that says you're ok with a WD being published but that you think that in a v1 WD, the I/O could be removed completely [1]. Sam Weinig voiced Apple's caveats which I responded to on public-webapps[2] wondering whether these caveats should block at least a WD publication [2], but these were really points about synchronous calls in general. By the way, just to clarify, none of my comments should IMO block publishing a Working Draft. A Working Draft is for review. But I do think we should start over with a v1 that is stripped down to the bare essentials, along the lines of Sam's proposal. I will add specifically that Apple is unwilling to implement any spec that allows synchronous file I/O from the main thread, and would vote against advancing such a spec to LC status or higher. Async I/O would be acceptable to us, but I think we have a considerable design process to go through in order to agree on how it works. I think the Blob API is not suitable as is. Regards, Maciej
Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec
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
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
Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec
On Thu, Oct 16, 2008 at 9:48 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 16, 2008, at 8:46 PM, Jonas Sicking wrote: 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. If the event cannot be manually created and dispatched, then how do you propose testing it? I'd like to see the unit test code that drives that one. Garrett Regards, Maciej
