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

Re: [FileAPI] Blob.URN?

From: Michael Nordman <michaeln@google.com>
Date: Wed, 24 Mar 2010 11:29:55 -0700
Message-ID: <o2jfa2eab051003241129v6dab8a20g96f9408343d3fc1@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Dmitry Titov <dimich@google.com>, Darin Fisher <darin@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
> Wouldn't it be better to have a constructor for File. File(Blob, name,
type, contentdisposition).

That could work, not sure its as intuitive. I think Files are destined to be
more often returned by various APIs and less often constructed by
application code directly. Wrapping a File/Blob in another File in order to
'override' whatever content-headers are baked into the original feels less
direct then specifying how you want the browser to view the File when given
a particular URL.

Mutable properties of the File object would be confusing. For example, does
setting the 'name' attribute rename the underlying file or tweeking type put
a new extension on the file name? The answer is no, but its easy to see how
somebody may expect that behavior.

I'd also like to point out that a getURL() method with an option to specify
the content -headers is compatible with a .url attribute that produces a URL
that will result in 'default' content-headers for the underlying File.

> Also, didn't we decide to change URN to URL? As far as I can tell that is
how Gecko is implementing it.

That may be, I dug this snippet up from an discussion long ago.


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:30:25 GMT

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