Re: [FileAPI] Blob.URN?

Sorry about the slow response, Dmitry.

On Wed, Mar 24, 2010 at 11:29 AM, Dmitry Titov <dimich@google.com> wrote:
> 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?

We could just disallow any parameter that doesn't make sense in this context.

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

Here's a previous discussion of some use cases:
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0506.html

> 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 Saturday, 3 April 2010 00:31:23 UTC