Re: FileUpload Editor | Re: File Upload Status ?

On Sat, Sep 6, 2008 at 8:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.
>

Well, we're now talking about file upload and file reading.

FileUpload is overlapping the use case of FormSerialization.

For a File Editor application, there would have to be an API for
reading and writing files. We'd need a Reader/Writer, and I think an
interface would be most aptly suited for such job. A FileReader could
be got off a file.

Async would avoid problems with Sync reads/writes.

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

Opera seem to include a lot of functionality for dealing with the user's system.

Is the goal to save the file using the "Save As" dialog, or to get the
data from a File (and save using another storage API)?

storage APIs already exist. Save As has familiar UI, but puts burden
of file location management on user. It's a different use case.


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

Use cases for File Read:

1. Lyrics Viewer
  User wants to read song lyrics from songs in his plist file.
  User browses for plist file.
  File is opened, read, parsed, and presented to the user
  as a sortable, actionable list.
  User can select songs to fetch lyrics.
  User uses the "browse for file" dialog.

2. Calendar App
  User's company has a calendar
  User wants to sync local events to company calendar, marked
  as "busy" slots (without leaking personal info)
  User browses for file and selects it. The text/calendar file is parsed
  in the browser,
  allowing the user to merge the files to one calendar view.
  The user wants to then save the file back to his local calendar file.
(using "Save As" ?)

3. Web-based Attachments
  The user wants add an "in-line" attachment to a message.
  The attachment should be displayed in the message.
(requires reading file data)

2. Calendar App:
<form action="">
  <input type="file" id="fileInput" onchange="readTextFile(this)">
  <input type="button" onclick="saveFileData(fileInput)">
</form>

<script type='text/javascript'>
/**
 * Reads a local file and updates the calendar view.
 */
function readTextFile(fileInput) {
  var reader;
  if(!/^text\/calendar$/.test(fileInput.mimeType)) {
    alert('please select a text file');
    return;
  }
  if(fileInput.fileSize > 4096) {
    alert('please choose a file under 4k');
    return;
  }
  // Get the reader for the data.
  reader = fileInput.getReader();
  setTimeout(errorHandler, 3000);

  reader.onerror = errorHandler;
  reader.onsuccess = showFileContents;
  reader.read();

  function showFileContents(e) {
    // read calendar local XML file.
    var data = e.data;
    // merge with web-based calendar.
  }
}

function errorHandler(e){
  textAreaEl.innerHTML = "Error Reading File.\n" +
  (e && e.message) || " Could not read file" ;
}

function saveFileData(fileInput) {
  // use a storage API to save calendar data in app.

  // Use "save as" to bring up "Save As" dialog.
  fileInput.browseForSave()
}
</script>
>
> I agree we should first discuss use cases and requirements, before coming up
> with APIs.
>

Garrett

> / Jonas
>

Received on Sunday, 7 September 2008 21:11:25 UTC