Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec
On Oct 17, 2008, at 11:46 AM, Arun Ranganathan wrote: All, Maceij wrote: [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. 1. Again, I apologize for embarking on a direction that wasn't what Apple envisioned, but your intention to make [3] above a v1 in lieu of the a more expansive spec. wasn't clear to me. Also, I didn't respond to the thread because Jonas' post affirming that it ... sounds like a great idea... was sufficient. Thus, I took the proposal as a key component in a more expansive spec., but not as a v1 spec. in and of itself. Would you be against making it a v1 spec in and of itself? Regards, Maciej
Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec
On Thu, 23 Oct 2008 12:59:58 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: Would you be against making it a v1 spec in and of itself? This e-mail thread is quite confusing. From what I gathered during the Web Apps F2F this week people were not ok with not having some kind blob API. The ability to split up a large file in a number of smaller files so you can e.g. resume upload if something goes wrong from a particular point was important. Everyone was ok with having access to the file data be asynchronous as far as I could tell. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec
All, Maceij wrote: [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. 1. Again, I apologize for embarking on a direction that wasn't what Apple envisioned, but your intention to make [3] above a v1 in lieu of the a more expansive spec. wasn't clear to me. Also, I didn't respond to the thread because Jonas' post affirming that it ... sounds like a great idea... was sufficient. Thus, I took the proposal as a key component in a more expansive spec., but not as a v1 spec. in and of itself. 2. Posts to this listserv by various Apple engineers about the perils of a synchronous I/O API have made good, cogent arguments. Moreover, Maciej suggests that Apple *won't* implement a specification with such APIs. I discussed this with Jonas; we're amenable to dropping these from the specification, and thus, I no longer consider this a major blocking issue in any way. Going forward, Mozilla may move developers away from our own synchronous APIs provided we agree on something that works in this specification, but that remains TBD. 3. Maciej, you state that you're in the process of posting to this listserv what's wrong with the Blob approach [1]. It was, after all, a strawperson for an asynchronous API, and thus I thought it worth including in a v1 specification. Note that I started with only the slice() method. I look forward to your commentary, since this will allow me to better justify not considering it till a v2. In retrospect, I'm glad I solicited commentary with the small amount of spec. text that I did add, as opposed to my other modifications ;-) I suppose this one goes back to the drawing board; in the long run, this may be desirable anyway. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0118.html
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
Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec
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. Going further back in time, Sam Weinig proposed standardizing a way to use XHR to send files [3], *without* specific ways to get the contents of files, leaving room for Blob and other stuff in nsIDOMFile (we can probably send Blobs or files). Nothing in the editor's draft precludes that! Also Sam's email refers to FileHTMLInputElement which exists in this draft as well (named HTMLFileInputElement). I can give specific technical comments on the things that I think are wrong with this draft, *Please do.*. This editor's draft is very rough, and doesn't reflect fait accompli thinking. If you think it too much of a union, maybe I should go back and start with a more basic v1, rather than include directions we may want to go in anyway? In another email, you suggest Apple thinks direct I/O should be added later[4], maybe along the lines of Blob, which is why I went with work in progress -- to add features we may want to evolve *anyway.* Perhaps we can have the definitive discussion on synchronous vs. asynchronous (and whether a spec. should allow both) and move on. I don't think anyone at Mozilla holds entrenched views here. I'm pretty optimistic that we can hash this out soon, and we should be able to push this spec. out sooner rather than later. It's been stagnant for a long-ish time :-) -- A* [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