Re: [FileAPI] Blob.URN?

On Fri, Apr 2, 2010 at 5:34 PM, Eric Uhrhane <ericu@google.com> wrote:

> On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher <darin@chromium.org> wrote:
> > On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >>
> >> On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher <darin@chromium.org>
> wrote:
> >> > Apologies if this has been discussed before, but I'm curious why URN
> is
> >> > not
> >> > a property of Blob.  It seems like it would be useful to be able to
> load
> >> > a
> >> > slice of a File.  For example, this could be used by an application to
> >> > fetch
> >> > all of its subresources out of a single file.
> >>
> >> IIRC originally it was placed on File since Blobs do not have a
> >> content type. However I think there is general agreement that it
> >> should be moved to Blob.
> >>
> >> However it would be great to be able to assign a content type to a
> >> Blob. Possibly slice() could take a optional argument.
> >>
> >
> > Adding an optional parameter to slice() sounds attractive indeed.
> > BlobBuilder [1] should probably also have such an optional argument.
> > -Darin
> > [1]
> http://dev.w3.org/2009/dap/file-system/file-writer.html#the-blobbuilder-interface
>
> That seems reasonable.  But if we move the content type and
> disposition to the Blob, and can get a URL from a Blob, then File is
> left with...just a name?
>
>
I think being actually stored in the local file system is the biggest
difference between Blob and File. For example, it can be found there again
(assuming we'll get capability to store File, as a reference, in database),
after the page closes. Or find it there if there is some name convention.