Re: [File API] Recent Updates To Specification + Co-Editor

+1 to

window.createBlobUrl(blob) and
window.revokeBlobUrl(url)

, they make lifetime of a blob url (which is different from lifetime of the
Blob JS object) way more clear to me, since it attaches it explicitly to a
window, and to a specific window in that. Multi-window web apps (like GMail
or IM) have multiple windows that cross-script each other, so it's very easy
to change the code a little and the 'spawning Document", as defined in the
spec now, changes, since it's implicitly captured. Explicit is good.

It also indeed makes it possible for a good-behaving app to prevent a memory
leak in long-lived pages and potentially shared workers, since it gives an
explicit 'revoke' method.

Nice idea, lets see if it can be added to the spec.

Dmitry

On Wed, Jun 30, 2010 at 5:38 PM, Jian Li <jianli@chromium.org> wrote:

> Thanks for the update. We've some more questions regarding the blob URL.
>
> 1. The spec does not describe how blob and blob URL will work in the worker
> and shared worker scenarios. I think we should allow WorkerGlobalScope to be
> the binding context for the blob URL, like Document. In addition, we should
> define how a blob object can be passed to the worker via structured cloning.
> A new blob object should be expected to be created and it points to the same
> underlying data.
>
> 2. The current spec says that the lifetime of the blob URL is bound to the
> lifetime of the spawning context. What happens if we try to access the blob
> url from multiple contexts? Say, we
> call "parent.blob.url", the lifetime of the url is bound to the parent
> context, not the current context, per the spec. This sounds a little bit
> unnatural. Could we explicitly provide the context while creating the blob
> URL, like "window.createBlobUrl(blob)"?
>
> 3. Since the lifetime of the blob URL is bound to a context, the blob URL
> (the underlying blob data) will get disposed only when the context dies.
> When we have long-live pages or shared workers, we could have "leaked" blob
> URLs that result in unclaimed blob storages. It will be nice if we can add
> the capability to revoke the blob URL pragmatically,
> like "window.revokeBlobUrl(url)",
>
> 4. It will be good if the spec could say more about the lifetime of the
> blob object and the blob URL since they're kind of orthogonal: the blob
> object will still be functional as long as it is not GC-ed even if the
> associated context dies.
>
> 5. The spec does not describe explicitly about the transient cases, like
> "location.href = blob.url". Probably the spec could mention that the
> resource pointed by blob URL should be loaded successfully as long as the
> blob URL is valid at the time when the resource is starting to load.
>
>
> On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan <arun@mozilla.com>wrote:
>
>> Greetings WebApps WG,
>>
>> I have made edits to the File API specification [1].  There are a few
>> things of note that I'd like to call the WG's attention to.
>>
>> 1. There is a name change in effect.  FileReader has been re-named
>> BlobReader, upon request from Chrome team folks[2][3].  The name
>> "BlobReader" won't win awards in a beauty pageant, but it tersely describes
>> an object to read Blobs (which could originate from the underlying file
>> system *or* be generated *within* a Web App).  My present understanding is
>> that FileWriter will also undergo a name change.  Naming is really hard.
>>  Firefox already ships with FileReader, but I see the point of having an
>> object named for what it does, which in this case is certainly more than
>> file reading from the underlying file system.  I also abhor bike shedding,
>> especially over naming, but this is something that's exposed to the authors.
>>  I have not renamed FileError or FileException.  In the case of errors and
>> exceptions, I think *most* scenarios will occur as a result of issues with
>> the underlying file system.  These names should remain.
>>
>> 2. I've updated the URL scheme for Blobs using an ABNF that calls for an
>> "opaque string" which is a term I define in the specification.  There was
>> much discussion about this aspect of the File API specification, and I think
>> the existing scheme does allow for user agents to tack on origin information
>> in the URL (this is not something the spec. says you should do).  The actual
>> choice of opaque string is left to implementations, though the specification
>> suggests UUID in its canonical form (and provides an ABNF for this).  I
>> think this is the most any specification has said on the subject of URLs.
>>
>> 3. There is an additional asynchronous read method on BlobReader, and an
>> additional synchronous read method on BlobReaderSync, namely
>> readAsArrayBuffer.  These use the TypedArrays definition initially defined
>> by the WebGL WG [4].
>>
>> 4. I am moving on from my full-time role at Mozilla to a part-time
>> consulting role.  I'll continue to be an editor of the File API, but I am
>> stepping down as Chair of the WebGL WG.  I'll continue to be active in
>> standards communities, though :-)
>>
>> 5. I spoke to Jonas Sicking, who expressed willingness to be a co-editor
>> of the File API specification.  Most people who work on HTML5 and WebApps
>> know Jonas' contributions to both WGs; with everyone's consent, I'd like to
>> nominate him as co-editor.  His model for an asynchronous event-driven API
>> is what prompted the initial rewrite, and he also works on both File API and
>> IndexedDB implementation (amongst other things).
>>
>> -- A*
>>
>> [1] http://dev.w3.org/2006/webapi/FileAPI/
>> [2]
>> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0755.html
>> [3]
>> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0716.html
>> [4]
>> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
>>
>>
>