W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 16 Oct 2008 20:02:18 -0700
To: arun@mozilla.com
Cc: Web Applications Working Group WG <public-webapps@w3.org>
Message-id: <BA40F394-A5E3-4319-813F-79656302212A@apple.com>


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

Our proposal was to publish *only* that API on v1, so that agreement  
on the right way to access file data would not be a blocker to what we  
saw as a consensus API that everyone would be willing to implement as- 
is.

Publishing v1 with a whole bunch of other stuff in it instead does not  
take account of that feedback.

You did not ever post to that email thread, so I'm not sure if you  
considered the proposal.

>
>> 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 :-)

I think you should start with Sam's proposal instead of Robin's old  
draft, and only add things that are clearly needed and where we have  
consensus on the right design. We have heard from Web developers that  
just the set of features in Sam's proposal (which I believe we could  
achieve 100% consensus on without significant delay or debate) would  
be immediately useful.

I would rather start with too little and add incrementally, than start  
with too much and have to argue about what to remove.

Does anyone disagree with that approach?

Regards,
Maciej
Received on Friday, 17 October 2008 03:03:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT