On Oct 15, 2008, at 11:54 PM, Jonas Sicking wrote:
On Wed, Oct 15, 2008 at 10:57 PM, Arun Ranganathan
<[EMAIL PROTECTED]> 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
