Re: FileUpload Editor | Re: File Upload Status ?

Garrett Smith wrote:
> 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.

I don't agree. The two seems totally unrelated. Sure, if you have file 
serialization a JS library could implement form serialization. However 
we're talking about specs that UAs would implement, which can be done 
totally without public APIs.

> But then, is there a strong need for File
> Serialization? Am I sufferering from 'analysis paralysis'?

Getting to file data is useful for many many other things than sending 
that data to a server. For example asking the user for a file containing 
data to process, or a word document to open and edit in google docs.

>> 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?

File download is when a page has some data that it wants to make 
available to the user to save as a local file. For example a result from 
a computation, or a document produced in google docs.

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

In the above example you are not interested in sending the data to the 
server, but rather providing to the user to save locally.

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

That seems like a fine example :)

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

I agree we should first discuss use cases and requirements, before 
coming up with APIs.

/ Jonas

Received on Sunday, 7 September 2008 03:40:15 UTC