W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: File API Feedback

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Sat, 27 Jun 2009 14:44:08 +0200
Message-ID: <65307430906270544o265b10f5p239f4284bcbcd579@mail.gmail.com>
To: arun@mozilla.com
Cc: WebApps WG <public-webapps@w3.org>
2009/6/25 Arun Ranganathan <arun@mozilla.com>:
> Giovanni,
>
>> For what concerns the "file as URI" feature:
>> What about reusing the "cid" scheme?
>>
>>
>
> This is an intriguing idea.  Other ideas I've experimented with include
> filedata:// but since cid has seen some usage (e.g. within email), it might
> be a good candidate.
>
> Upon reflection, the research this task would take might delay a first draft
> of the FileAPI spec.

We don't need to put it into the FPWD (or even the version 1.0 of final API)

>> - It would avoid collisions, as anything can be used as Content-ID,
>> including a progressive number or the name of the input element
>>
>
> This makes a good case for cid:<inputElementName> but we ought to allow for
> files that aren't selected using input elements :)

The browser could assign a Content-Id to the file selected by the
JS-invoked dialog box.

>> - It would not be problematic to implement, as "cid" URIs are already
>> supported by browsers
>>
>
> This isn't quite true for Firefoc -- see for example
> https://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&forumId=1&comments_parentId=189767
> .

Just an implementation bug, I guess.

> If we go this route, this may enable other use case scenarios as well.
>>
>> - It would respect theoretical purity, as the identifier actually
>> represents the Content-ID of the file subpart in the
>> "multipart/form-data" submission
>>
>
> Theoretical purity is wonderful in theory ;-)

Something good in both theory and practice is better than something
else only good in practice.

>> - It would bind to the <input type=file>: changing the file selected
>> automatically changes the reflected content, and the application
>> cannot send or read files the user had selected and then changed (not
>> through this API, at least)
>>
>
> My first impression is that this seems like an attractive capability.

Good.

>> Lastly: a new approach to the "file dialog" feature is
>> "about:fileselection", ie an URI that represents the file dialog box.
>> The difference between this and FileDialog is that it can be used from
>> an <iframe>, to avoid proliferation of modal dialog boxes.
>
> So this would be *another* URI scheme to refer to the opened file dialog?
>  This seems like overkill.

The "about:" URI scheme exists for "browser stuff".
It would just be a binding from a new value for about (fileselection)
to "chrome://browser/user-interface/filedialog" or
"res://comctl32.dll\filechooser" or
"file:///usr/share/my-browser/ui/fileselection".
It is not that difficult (else they would not use about: for easter eggs)

> -- A*
>

Giovani
Received on Saturday, 27 June 2009 12:44:49 GMT

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