W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: FileUpload Editor | Re: File Upload Status ?

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Fri, 5 Sep 2008 17:50:13 -0700
Message-ID: <c9e12660809051750j10e2d0a6i3a75b5c20f50fdd@mail.gmail.com>
To: arun@mozilla.com
Cc: "Web Applications Working Group WG" <public-webapps@w3.org>, "Maciej Stachowiak" <mjs@apple.com>, "Oliver Hunt" <oliver@apple.com>, "Jonas Sicking" <jonas@sicking.cc>

On Fri, Sep 5, 2008 at 12:28 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> All,
>

Hi Arun,

> On behalf of Mozilla, I'd like to take over as editor of the FileUpload
> spec., which was actually once assigned to me quite some time ago :)
>
> Of course, I think that
>>
>> form.getDataAsString();
>>
>
> form serialization is out of scope of this particular specification, but I

I agree, but it seems that File Serialization is a prereq to Form
Serialization. But then, is there a strong need for File
Serialization? Am I sufferering from 'analysis paralysis'?

> think other things like Blobs (as per the Google Gears proposal -- maybe a
> File interface can have a getBlobs on it) are probably in, as well as some
> other interface proposals by Opera, etc.  Security makes or breaks all of
> this, so I'll start with the restrictions we've put on this as a
> strawperson.  After talking to Jonas, I also think "File Download" should be
> in scope, again modulo security which, following a straw person, is a
> welcome group discussion.
>

How does "File Download" work?

Would it be better to provide only the ability to access files'
mediaType, and fileSize, and let XHR accept a File to send()?

Reading a file locally would allow for populating a Rich Text Editor
without a trip to the server. There may be other cases for needing the
data inside a file on the client, but I can't think of them.

> I've gotten CVS access from Mike.  I'd like till the end of the week (next
> week) to turn around a a first revision.
>

Writing documentation and then writing code has led API problems that
could have been avoided.

To avoid this problem, before writing documentation, it would be a
good idea to figure out what the goal of the API is. Informal
discussion could accomplish that. Next, I would like to see a test
case. The test case would accomplish figuring out what the API will
do, plus reveal edge cases and problems.

I know this is not the way things usually get done.

My reason for emailing to ask for feedback from Jonas, Maciej, and
Oliver, and the public-webapps list, was to get the ball rolling by
this less formal process. I would like to know what the API should do
and then write a test case that expects such functionality.

Regardless of my opinions of process, it's good to see some else take
an interest and initiative on this, Arun.

Thank you,

Garrett

> -- A*
>
Received on Saturday, 6 September 2008 00:50:53 GMT

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