W3C home > Mailing lists > Public > public-webapi@w3.org > September 2006

Re: Comments on File Upload

From: Robin Berjon <robin.berjon@expway.fr>
Date: Fri, 22 Sep 2006 11:06:05 +0000
Message-Id: <DB87A272-9CE3-44CA-B01C-65783D68B2D5@expway.fr>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
To: Mark Baker <distobj@acm.org>

Hi Mark,

thanks a lot for your review.

On Sep 21, 2006, at 15:18, Mark Baker wrote:
> Editorial;
>
> - sec 1, "This interface" should be "This specification"
> - sec 3, I'd suggest s/apparition/display/

Applied.

> Substantive;
>
> - sec 3, regarding "On devices that have no file system, the
> user-agent MAY still open a dialogue for data acquisition, for
> instance an interface to a built-in camera", my concern is that  the
> file dialogue should be considered generic, not specific to any form
> of data, so I don't want to give the impression that the device can
> choose the data without user involvement.  So I'd suggest "for
> instance, a dialog which identifies a built-in camera and a
> microphone".

Agreed, I've made a change similar to your suggestion.

> - sec 4, not that I care that much, but do we really need this
> interface? Would an array not suffice?  It can't do remove, of course,
> but is that such a big deal?

I'm not at all a big fan of all the FooList interfaces that show up  
here and there in W3C APIs, but I'm unsure as to how to handle this  
in a language-independent manner. What it maps to is binding-specific  
mind you, so in ES it would certainly have the behaviour of an array.  
I think that once we make progress on the "Bindings for ES"  
specification (Jonas?) we'll see more clearly on this issue.

> - sec 4, I don't think "SHOULD" is appropriate there, for selecting
> multiple files - MAY should be fine.  Plus I think it's best specified
> in sec 3.

I've moved it to section 3 as I agree that it does make more sense  
there. However I do think that the SHOULD is justified here. If the  
platform on which the UA is running has a way of selecting multiple  
files, then it definitely must do it  the single file selection of  
UAs since the introduction of input type=file has been a genuine  
pain. The only reason it is a SHOULD and not a MUST is due to  
hypothetical platforms that may not have a FS (as mentioned two  
points above). I have half a mind to forget about that and make it a  
MUST. What do you think?

> - sec 5, filesize - do we know the use cases for this?

Yes, a non-negligible number of sites request that users not upload  
files bigger than X. This does not provide for server security, but  
it gives the page a chance to tell the user that a file is too big  
before it is submitted.

> I don't think
> the definition provided would be useful for much beyond scenarious
> using some files in a file system.

Well, that is the primary use case :)

>   What if a camera had an 8MB
> buffer, but image sizes could be up to that size?  Or similarly, what
> about an audio stream?  And is this meant to be a string?

No, it's definitely not meant to be a string, good catch.

> - sec 5, mediatype - do both "" and null values indicate that the
> agent doesn't know the media type?  And are we expecting this to be
> just be the "foo/bar" value, or would parameters also be included?
> Need some references too.

Good questions, I've added an editorial note to that effect.

Thanks!

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/
Received on Friday, 22 September 2006 11:43:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:55 GMT