Garrett Smith wrote:
On Fri, Sep 5, 2008 at 12:28 PM, Arun Ranganathan <[EMAIL PROTECTED]> 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
