W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [FileAPI] Blob.URN?

From: Dmitry Titov <dimich@google.com>
Date: Wed, 24 Mar 2010 11:29:28 -0700
Message-ID: <l2g28040fc61003241129hcd626416m648b402d0b3534c8@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Michael Nordman <michaeln@google.com>, Darin Fisher <darin@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
Those seem to open up so many edge cases...

If we have a File constructor like this, now we have a new category of File
objects that do have names but are not related to actual files on a local
file system, and perhaps have different lifetime expectations.

Ability to specify a name and content disposition also does not fall in
naturally. For example, is what happens when a blob with 'inline'
disposition used in anchor's href or iframe's src? What happens if one
specifies the creation/modification time parameters? What would it mean to
specify a size parameter in content disposition when underlying Blob also
has size property?

Even one step back, are we sure there is a use case for Blob.urn? If Blobs
are sliced from the files on a local filesystem that user selected via a
File Dialog, what would be a scenario for slice/load? There were requests to
have a single network resource that can be slice/loaded on arrival, but was
the slicing and loading of local files discussed? The most obvious use case
for local files is to be uploaded, perhaps in slices.

On Wed, Mar 24, 2010 at 1:58 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman <michaeln@google.com>
> wrote:
>
>> This has been discussed before, not sure what the conclusion was (if any)
>> http://www.mail-archive.com/public-webapps@w3.org/msg06137.html
>>
>> <http://www.mail-archive.com/public-webapps@w3.org/msg06345.html><snip>
>>
>>
>> In order for the URN to be useful, it would have to have a mediaType
>> associated with it, and then there's content-disposition to think
>> about, which then wants a file name as well...boy, that's a lot of
>> baggage.  However, since these aren't really inherent properties of
>> the Blob, just of the way you want the browser to view the Blob, it
>> would seem natural to me do to something like this:
>>
>>    interface Blob {
>>      ...
>>      DOMString getURN(in DOMString mediaType,
>>           [Optional] in DOMString contentDisposition,
>>           [Optional] in DOMString name);
>>    };
>>
>> </snip>
>>
>
> Wouldn't it be better to have a constructor for File. I.e.
>
>  File(Blob, name, type, contentdisposition)
>
> or some such. (Maybe some of the attributes on File should be made mutable,
> i.e. name and mime...)
>
>
> Also, didn't we decide to change URN to URL? As far as I can tell that is
> how Gecko is implementing it.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
Received on Wednesday, 24 March 2010 18:29:58 GMT

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