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

On Thu, Jul 1, 2010 at 11:47 AM, Dmitry Titov <dimich@chromium.org> wrote:

> +1 to
>
> window.createBlobUrl(blob) and
> window.revokeBlobUrl(url)
>

+1 too, presumably these would also be available workers, particularly
shared workers.


> , 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.
>
>
By factoring the .url property out, the Blob object itself acts much more
like a String primitive in that it's an immutable container for data that
can be passed freely throughout a graph of connected browsing contexts, and
potentially serialized and sent via PostMessage. Overall simpler to grok w/o
the 'spawning context' concept.


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