RE: [fileapi] Pull Request on GitHub

[Adrian Bateman]

> On Wed, Aug 17, 2016 at 11:38:59, Marijn Kruisselbrink wrote:
> Sorry about that. Somehow that PR slipped through the cracks. I've commented
> on the PR.
> 
> Anybody knows what the deal is with the ipr check? What makes it fail, and if
> it fails who is supposed to do what to not make it fail?

This happens when someone who is not a recognized (by the tool) member of
the WG makes a pull request.

Since this looks like only editorial changes, we'll mark it as non-substantive.

Cheers,

Adrian.

Re: [fileapi] Pull Request on GitHub

[Marijn Kruisselbrink]

On Tue, Aug 16, 2016 at 11:43 AM, Arun Ranganathan 
wrote:

> I won't be editing it either.
>
> On Tue, Aug 16, 2016 at 4:44 AM, Marcos Caceres 
> wrote:
>
>> On August 16, 2016 at 6:31:31 PM, Zhen Zhang (izgz...@gmail.com) wrote:
>> > Hi,
>> >
>> > I have a PR on GitHub regarding some issues of wording in current File
>> API spec: https://github.com/w3c/FileAPI/pull/42
>> > , but nobody ever responded me there.
>> > I wonder if I should discuss the patch somewhere else?
>>
> Sorry about that. Somehow that PR slipped through the cracks. I've
commented on the PR.

Anybody knows what the deal is with the ipr check? What makes it fail, and
if it fails who is supposed to do what to not make it fail?

It seems that no one has touched that API for about 8 months.
>>
> Not sure where you're getting 8 months from? I definitely still have
catching up with outstanding issues to do, but I have been doing work on
the API significantly more recent than 8 months.


> Marijn, are you still editing that document? I guess Jonas won't be,
>> but not sure about Arun.
>>
> Yes, I'm still editing that document. Just haven't had time yet to fully
catch up with outstanding issues/comments.

Re: [fileapi] Pull Request on GitHub

[Arun Ranganathan]

I won't be editing it either.

On Tue, Aug 16, 2016 at 4:44 AM, Marcos Caceres  wrote:

> On August 16, 2016 at 6:31:31 PM, Zhen Zhang (izgz...@gmail.com) wrote:
> > Hi,
> >
> > I have a PR on GitHub regarding some issues of wording in current File
> API spec: https://github.com/w3c/FileAPI/pull/42
> > , but nobody ever responded me there.
> > I wonder if I should discuss the patch somewhere else?
>
> It seems that no one has touched that API for about 8 months.
>
> Marijn, are you still editing that document? I guess Jonas won't be,
> but not sure about Arun.
>
>

Re: [fileapi] Pull Request on GitHub

[Marcos Caceres]

On August 16, 2016 at 6:31:31 PM, Zhen Zhang (izgz...@gmail.com) wrote:
> Hi,
>
> I have a PR on GitHub regarding some issues of wording in current File API 
> spec: https://github.com/w3c/FileAPI/pull/42
> , but nobody ever responded me there.
> I wonder if I should discuss the patch somewhere else?

It seems that no one has touched that API for about 8 months.

Marijn, are you still editing that document? I guess Jonas won't be,
but not sure about Arun.

Re: [FileAPI] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]

[Arun Ranganathan]

On Oct 22, 2014, at 8:05 AM, Arthur Barstow art.bars...@gmail.com wrote:

 * File API: Arun and Jonas; which v1 bugs are blocking a new LC; what are 
 next steps; timeline for LC.
 
 Arun, Jonas,
 
 Please see the above and respond accordingly. I am especially interested in 
 the File API status but please also include a summary of your plans for the 
 the Filesystem API.



1. File API: happy to move towards LC. Only active bug is a platform bug:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26603

which applies to FileAPI’s use of the incumbent settings object for origin 
determination of Blob URLs.

2. FileSystem API: http://w3c.github.io/filesystem-api/Overview.html

Plan: get feedback from implementors, fix the spec and resolve the spec.’s 
issues. Thanks to Ali Alabbas from the IE Platform Team for some early feedback.

— A*

Re: [fileapi-directories-and-system/filewriter]

[Arthur Barstow]

On 4/2/14 12:36 PM, ext Eric U wrote:

Status:

  The specs are clearly dead; it's just been way down on my
priority list to do anything about it.  We should funnel it off to be
a Note [or whatever the proper procedure is--Art?].


Thanks for the quick reply Eric. When a group agrees to stop work on a 
spec (that was published as a Technical Report), it is expected to 
publish a Working Group Note of the spec.


I'll start a CfC to publish a WG Note for these specs.

-AB

Re: [FileAPI] LC Comment Tracking

[Arun Ranganathan]

Art,

All LC commentary (http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912) has 
been addressed and I think the draft is ready to be published as CR status.

The draft is: http://dev.w3.org/2006/webapi/FileAPI/

-- A*

On Nov 8, 2013, at 10:15 AM, Arun Ranganathan wrote:

 Hi Art,
 
 On Nov 7, 2013, at 9:40 AM, Arthur Barstow wrote:
 
 
 Since it appears you will not be at WebApps' f2f meeting next week, I would 
 appreciate it if you would please summarize the status of the comment 
 processing, your next steps, etc. I am especially interested in whether or 
 not you consider any of the bug fixes you applied as substantive and/or 
 add a new feature (which would require a new LC).
 
 
 Most LC commentary that was substantive became a spec bug; I've fixed most 
 such spec. bugs, and the contributor/commentor has been notified.
 
 In my opinion, the biggest change is to the File constructor.  This is 
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23479.  I don't think this is 
 a new feature, since the previous document pushed to /TR had a constructor, 
 athough a different signature.
 
 Other changes include moving Blob URL to be redefined in terms of terminology 
 in the WHATWG URL spec, in lieu of ABNFs.
 
 If you provide a dial-in on the day that you discuss File + FileSystem, I can 
 try and dial in, but this depends on time.  There will be others present from 
 Mozilla  :)  The LC commentary is tracked at 
 http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912
 
 -- A*
 
 
 
 -Thanks, ArtB
 
 [1] http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912
 
 
 On 9/12/13 10:39 AM, ext Arthur Barstow wrote:
 [ Bcc public-sysapps ; comments from SysApps are welcome ]
 
 This is a Request for Comments for the 12 September 2013 Last Call
 Working Draft of File API:
 
 http://www.w3.org/TR/2013/WD-FileAPI-20130912/
 
 The comment deadline is October 24 and all comments should be sent to
 the public-webapps@w3.org list with a subject: prefix of [FileAPI].
 
 The spec's bug list is [Bugs] and the few `approved` tests we have can
 be run in a browser at [Tests].
 
 -Thanks, ArtB
 
 [Bugs] http://tinyurl.com/Bugs-FileAPI
 [Tests] http://w3c-test.org/web-platform-tests/master/FileAPI/
 
 
 
 
 
 

Re: [FileAPI] LC Comment Tracking

[Arun Ranganathan]

Hi Art,

On Nov 7, 2013, at 9:40 AM, Arthur Barstow wrote:

 
 Since it appears you will not be at WebApps' f2f meeting next week, I would 
 appreciate it if you would please summarize the status of the comment 
 processing, your next steps, etc. I am especially interested in whether or 
 not you consider any of the bug fixes you applied as substantive and/or add 
 a new feature (which would require a new LC).


Most LC commentary that was substantive became a spec bug; I've fixed most such 
spec. bugs, and the contributor/commentor has been notified.

In my opinion, the biggest change is to the File constructor.  This is 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23479.  I don't think this is a 
new feature, since the previous document pushed to /TR had a constructor, 
athough a different signature.

Other changes include moving Blob URL to be redefined in terms of terminology 
in the WHATWG URL spec, in lieu of ABNFs.

If you provide a dial-in on the day that you discuss File + FileSystem, I can 
try and dial in, but this depends on time.  There will be others present from 
Mozilla  :)  The LC commentary is tracked at 
http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912

-- A*



 -Thanks, ArtB
 
 [1] http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912
 
 
 On 9/12/13 10:39 AM, ext Arthur Barstow wrote:
 [ Bcc public-sysapps ; comments from SysApps are welcome ]
 
 This is a Request for Comments for the 12 September 2013 Last Call
 Working Draft of File API:
 
 http://www.w3.org/TR/2013/WD-FileAPI-20130912/
 
 The comment deadline is October 24 and all comments should be sent to
 the public-webapps@w3.org list with a subject: prefix of [FileAPI].
 
 The spec's bug list is [Bugs] and the few `approved` tests we have can
 be run in a browser at [Tests].
 
 -Thanks, ArtB
 
 [Bugs] http://tinyurl.com/Bugs-FileAPI
 [Tests] http://w3c-test.org/web-platform-tests/master/FileAPI/
 
 
 
 

Re: [FileAPI]

[Arthur Barstow]

Hi,

For the purposes of tracking your comments for the September 12 File API 
Last Call Working Draft, please let us know if Arun's reply is 
satisfactory or not. In the absence of a reply from you by November 7, 
we will assume Arun's reply is OK with you.


-Thanks, ArtB

On 10/23/13 6:04 PM, ext Arun Ranganathan wrote:

Hi there!


On Oct 23, 2013, at 12:32 PM, psweatte wrote:


7.2 Interface File:
-add creationDate property


Thanks for your feedback.  *Most* filesystems don't really have a creation time.  
While Windows does, Unix-style OS return the *change time or last modified 
time.  Since we want fidelity with OS filesystems wherever possible, I'm not sure 
this is a viable property to add.



-add size property

This already exists via the inheritance relationship with Blob.



-If the last modification date and time are not known, the attribute must 
return an empty string


Currently the spec says to return the current date and time.  It's a Date not a 
String.



8.3. Event Handler Attributes


I think the current set of event handler attributes is sufficient, especially 
given the backdrop of event models in general not being the best way to 
asynchronously access large data sets such as File and Blob.



-add onNotfounderror event handler
-add onReaderror event handler
-add onSecurityerror event handler
-add onHTTPerror event handler
-add onSelectfrombrowse event handler

Re: [FileAPI]

[Arun Ranganathan]

Note that all LC Commentary, including that sent on this listserv, is tracked 
here: 
http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912

-- A*
On Oct 31, 2013, at 9:12 AM, Arthur Barstow wrote:

 Hi,
 
 For the purposes of tracking your comments for the September 12 File API Last 
 Call Working Draft, please let us know if Arun's reply is satisfactory or 
 not. In the absence of a reply from you by November 7, we will assume Arun's 
 reply is OK with you.
 
 -Thanks, ArtB
 
 On 10/23/13 6:04 PM, ext Arun Ranganathan wrote:
 Hi there!
 
 
 On Oct 23, 2013, at 12:32 PM, psweatte wrote:
 
 7.2 Interface File:
 -add creationDate property
 
 Thanks for your feedback.  *Most* filesystems don't really have a creation 
 time.  While Windows does, Unix-style OS return the *change time or last 
 modified time.  Since we want fidelity with OS filesystems wherever 
 possible, I'm not sure this is a viable property to add.
 
 
 -add size property
 This already exists via the inheritance relationship with Blob.
 
 
 -If the last modification date and time are not known, the attribute must 
 return an empty string
 
 Currently the spec says to return the current date and time.  It's a Date 
 not a String.
 
 
 8.3. Event Handler Attributes
 
 I think the current set of event handler attributes is sufficient, 
 especially given the backdrop of event models in general not being the best 
 way to asynchronously access large data sets such as File and Blob.
 
 
 -add onNotfounderror event handler
 -add onReaderror event handler
 -add onSecurityerror event handler
 -add onHTTPerror event handler
 -add onSelectfrombrowse event handler
 
 
 
 
 
 

Re: [FileAPI]

[Arun Ranganathan]

Hi there!


On Oct 23, 2013, at 12:32 PM, psweatte wrote:

 7.2 Interface File:
 -add creationDate property


Thanks for your feedback.  *Most* filesystems don't really have a creation 
time.  While Windows does, Unix-style OS return the *change time or last 
modified time.  Since we want fidelity with OS filesystems wherever possible, 
I'm not sure this is a viable property to add.


 -add size property

This already exists via the inheritance relationship with Blob.


 -If the last modification date and time are not known, the attribute must 
 return an empty string


Currently the spec says to return the current date and time.  It's a Date not a 
String.


 8.3. Event Handler Attributes


I think the current set of event handler attributes is sufficient, especially 
given the backdrop of event models in general not being the best way to 
asynchronously access large data sets such as File and Blob.


 -add onNotfounderror event handler
 -add onReaderror event handler
 -add onSecurityerror event handler
 -add onHTTPerror event handler
 -add onSelectfrombrowse event handler
 
 
 

Re: [FileAPI] Questions on using Blobs for img src and a href

[Arun Ranganathan]

On Oct 3, 2013, at 6:35 PM, Brian Matthews (brmatthe) wrote:


 First is the status bar display for anchors while hovering over them. As 
 expected, it's the blob URL. While this is completely correct and exactly 
 what I'd expect, I'm not sure how useful it is. For an anchor with a normal 
 URL, the user is told something about where the resource is (the domain name 
 and path, http://example.com/order;), and what it is (the last element of 
 the path, invoice.pdf). With a blob URL, they're told where it is (at least 
 for those who know what a blob URL is, or accept that blob:... is something 
 magic they don't need to know about :-) ), but nothing about what it is.


This is an implementation issue that goes beyond the spec. (as others have 
remarked, this kind of thing falls under the purview of UI/UX, which web 
specifications rarely touch on meaningfully), but I think it is probably a 
useful informative comment that I'll add as part of LC Commentary changes.

I think you should file bugs on all browser projects that you'd like to see 
this kind of thing implemented in.  It's a useful feature for end-users.


 Second, and related, is what happens when someone saves an image or target of 
 a link. In both cases with normal URLs, there's a name component and the 
 user agent can use that as the name of the resulting file, or suggest it if 
 doing a Save As With blob URLs, there is no name, so the user agent has 
 to make up a name. So with Firefox one gets fun names like index.gif (when 
 saving an img), or bf_UK+0O.gif and y+f+wR9a.pdf (when saving the target of 
 an anchor), and Chrome uses the opaqueString part of the URL, resulting in 
 names like 49c122d8-0958-4dfd-ac9c-0a6245c5f91f..gif. None of those exactly 
 brim with semantic content.


OK, I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23450

I'm not fully convinced by other commentors on this listserv that we should use 
Content-Disposition as how to do this.  I think how Save As is implemented is 
a detail left to browsers, but I think the part of using file name is useful 
during Save As.


 Also, 8.5.6 step 1 in the spec starts Fire a progress event called error. 
 Set the error attribute;. Doesn't firing an event call the event handlers 
 immediately? If so, this seems to be saying to call the error handler 
 *before* setting the error attribute,  which seems backwards.


Yes, I agree!  https://www.w3.org/Bugs/Public/show_bug.cgi?id=23451

Thanks for your thoughtful LC commentary.

-- A*

Re: [FileAPI] Questions on using Blobs for img src and a href

[Glenn Maynard]

On Thu, Oct 3, 2013 at 5:35 PM, Brian Matthews (brmatthe) 
brmat...@cisco.com wrote:

  I've been doing some prototyping around displaying images with img
 src=blob:... and providing links to content using a href=blob:
 I've got it working, and it's all very cool, but there are a couple of
 things that seem like they could work better. They might be things that are
 too user agent specific for the spec (http://www.w3.org/TR/FileAPI/) to
 comment on, but I thought I'd ask here and see if there's something I'm
 missing, and make a suggestion.


(FYI, the link you want is http://dev.w3.org/2006/webapi/FileAPI/.  Click
the Editor's Draft link at the top of the spec.  This TR link happens
to be recent, but they're often very out of date.)

 Note that from the spec one would think I could do a new File(myBlob,
 myFilename), but both Firefox and Chrome throw exceptions when I do that
 (is that expected?), and if I use a real File (from a FileList), the name
 doesn't flow through to the blob URL and isn't used when saving.


The File ctor is probably not implemented in browsers yet.  They definitely
should use the File's filename as the save-as hint, which may also not yet
be implemented.  You can file bugs on those browsers if you think it'll
help.

-- 
Glenn Maynard

Re: [FileAPI] Questions on using Blobs for img src and a href

[Kyle Huey]

Hi Brian,

Responses inline.

On Fri, Oct 4, 2013 at 6:35 AM, Brian Matthews (brmatthe) 
brmat...@cisco.com wrote:

  I've been doing some prototyping around displaying images with img
 src=blob:... and providing links to content using a href=blob:
 I've got it working, and it's all very cool, but there are a couple of
 things that seem like they could work better. They might be things that are
 too user agent specific for the spec (http://www.w3.org/TR/FileAPI/) to
 comment on, but I thought I'd ask here and see if there's something I'm
 missing, and make a suggestion.


I think that the first is an implementation bug.  The second is more
complicated.


  First is the status bar display for anchors while hovering over them. As
 expected, it's the blob URL. While this is completely correct and exactly
 what I'd expect, I'm not sure how useful it is. For an anchor with a
 normal URL, the user is told something about where the resource is (the
 domain name and path, http://example.com/order;), and what it is (the
 last element of the path, invoice.pdf). With a blob URL, they're told
 where it is (at least for those who know what a blob URL is, or accept that
 blob:... is something magic they don't need to know about :-) ), but
 nothing about what it is.


For instance, there's nothing in the spec requiring browsers to display
URIs on hover at all.  This is kind of a tricky UI problem (data URIs have
similar issues).  Browsers probably want to show that clicking the link
goes somewhere, but the URI doesn't provide any useful information to the
user.

Second, and related, is what happens when someone saves an image or target
 of a link. In both cases with normal URLs, there's a name component and
 the user agent can use that as the name of the resulting file, or suggest
 it if doing a Save As With blob URLs, there is no name, so the user
 agent has to make up a name. So with Firefox one gets fun names
 like index.gif (when saving an img), or bf_UK+0O.gif and y+f+wR9a.pdf
 (when saving the target of an anchor), and Chrome uses the opaqueString
 part of the URL, resulting in names
 like 49c122d8-0958-4dfd-ac9c-0a6245c5f91f..gif. None of those exactly brim
 with semantic content.


If a File object (which has a name) is used instead of a Blob I think we
should treat it as if something like Content-Disposition: filename=$
file.name was specified in an HTTP request.  I don't know if browsers
support Content-Disposition without inline/attachment specified.  This is
the sort of thing that would be appropriate to put in the spec.

While I might be (probably am) missing something, I don't think there's any
 work around for either. Even the standard
 onmouseover=window.status='map.gif' for the first doesn't work in most
 (all?) browsers these days. Given that, my suggestion would be to promote
 the name attribute from the File interface to the Blob interface, and use
 it (if not null) when constructing blob URLs:
 blob:49c122d8-0958-4dfd-ac9c-0a6245c5f91f/map.gif. When using such a blob
 URL to locate the Blob in memory, the user agent would ignore everything
 after the first slash (just as it does with #, and presumably, although the
 standard doesn't, but probably should, state such, ?). When saving the
 contents of the Blob on the filesystem, the user agent would use the Blob's
 name as the file name, and when doing a Save As... type operation, would
 suggest the same as the file name. Or, as an alternative to promoting the
 name attribute, scripts could add the file names (as they can add fragment
 identifiers (and query strings?) today) to blob URLs and the user agent
 would take everything between the last unescaped / and first unescaped # or
 ? as the file name.


I don't think we want to introduce yet another way to parse URIs (which is
what treating '/' as special for blob would do).

Note that from the spec one would think I could do a new File(myBlob,
 myFilename), but both Firefox and Chrome throw exceptions when I do that
 (is that expected?), and if I use a real File (from a FileList), the name
 doesn't flow through to the blob URL and isn't used when saving.


I suspect this is just not implemented yet.

- Kyle

Re: [FileAPI] Questions on using Blobs for img src and a href

[Boris Zbarsky]

On 10/4/13 10:48 AM, Kyle Huey wrote:

If a File object (which has a name) is used instead of a Blob I think we
should treat it as if something like Content-Disposition:
filename=$file.name http://file.name was specified in an HTTP
request.


Gecko does, because a bunch of servers send it.  See 
https://bugzilla.mozilla.org/show_bug.cgi?id=272541


And we support it by treating it identically to Content-Disposition: 
inline; filename=whatever.  Which is how I believe named Blobs should 
be handled.


-Boris

Re: [FileAPI] Questions on using Blobs for img src and a href

[Brian Matthews (brmatthe)]

On Thu, Oct 3, 2013 at 5:35 PM, Brian Matthews (brmatthe) 
brmat...@cisco.commailto:brmat...@cisco.com wrote:
I've been doing some prototyping around displaying images with img 
src=blob:... and providing links to content using a href=blob: I've 
got it working, and it's all very cool, but there are a couple of things that 
seem like they could work better. They might be things that are too user agent 
specific for the spec (http://www.w3.org/TR/FileAPI/) to comment on, but I 
thought I'd ask here and see if there's something I'm missing, and make a 
suggestion.

(FYI, the link you want is http://dev.w3.org/2006/webapi/FileAPI/.  Click the 
Editor's Draft link at the top of the spec.  This TR link happens to be 
recent, but they're often very out of date.)

I looked at all 3 and they're the same in this case, so I just used the 
shortest link, and the one that comes up first when you search w3.org. If the 
Editor's Drafts are the newest, I'll look at and reference those in the future.

Note that from the spec one would think I could do a new File(myBlob, 
myFilename), but both Firefox and Chrome throw exceptions when I do that (is 
that expected?), and if I use a real File (from a FileList), the name doesn't 
flow through to the blob URL and isn't used when saving.

The File ctor is probably not implemented in browsers yet.  They definitely 
should use the File's filename as the save-as hint, which may also not yet be 
implemented.  You can file bugs on those browsers if you think it'll help.

It's implemented somewhat, although maybe it's just a stub that throws an 
exception. I'll come up with a test case and write bugs on at least Firefox and 
Chrome. That will only get me part way there though, as they don't seem to use 
the name even when it's there, but maybe that's another set of bugs..

Thanks,
Brian

Re: [FileAPI] Questions on using Blobs for img src and a href

[Brian Matthews (brmatthe)]

On 10/4/13 7:48 AM, Kyle Huey m...@kylehuey.commailto:m...@kylehuey.com 
wrote:
Second, and related, is what happens when someone saves an image or target of a 
link. In both cases with normal URLs, there's a name component and the user 
agent can use that as the name of the resulting file, or suggest it if doing a 
Save As With blob URLs, there is no name, so the user agent has to make up 
a name. So with Firefox one gets fun names like index.gif (when saving an 
img), or bf_UK+0O.gif and y+f+wR9a.pdf (when saving the target of an anchor), 
and Chrome uses the opaqueString part of the URL, resulting in names like 
49c122d8-0958-4dfd-ac9c-0a6245c5f91f..gif. None of those exactly brim with 
semantic content.

If a File object (which has a name) is used instead of a Blob I think we should 
treat it as if something like Content-Disposition: 
filename=$file.namehttp://file.name was specified in an HTTP request.  I 
don't know if browsers support Content-Disposition without inline/attachment 
specified.  This is the sort of thing that would be appropriate to put in the 
spec.

If that's used as the suggested name for saving, that would fix my second issue 
(and if I could create my own File with new File(blob, name)).

While I might be (probably am) missing something, I don't think there's any 
work around for either. Even the standard onmouseover=window.status='map.gif' 
for the first doesn't work in most (all?) browsers these days. Given that, my 
suggestion would be to promote the name attribute from the File interface to 
the Blob interface, and use it (if not null) when constructing blob URLs: 
blob:49c122d8-0958-4dfd-ac9c-0a6245c5f91f/map.gif. When using such a blob URL 
to locate the Blob in memory, the user agent would ignore everything after the 
first slash (just as it does with #, and presumably, although the standard 
doesn't, but probably should, state such, ?). When saving the contents of the 
Blob on the filesystem, the user agent would use the Blob's name as the file 
name, and when doing a Save As... type operation, would suggest the same as the 
file name. Or, as an alternative to promoting the name attribute, scripts could 
add the file names (as they can add fragment identifiers (and query strings?) 
today) to blob URLs and the user agent would take everything between the last 
unescaped / and first unescaped # or ? as the file name.

I don't think we want to introduce yet another way to parse URIs (which is what 
treating '/' as special for blob would do).

It would be a change, although a small one, blob URL parsing already has to 
look for # (and ??), and it would be very similar to parsing other URL schemes, 
but yeah, it would be a change.


Note that from the spec one would think I could do a new File(myBlob, 
myFilename), but both Firefox and Chrome throw exceptions when I do that (is 
that expected?), and if I use a real File (from a FileList), the name doesn't 
flow through to the blob URL and isn't used when saving.

I suspect this is just not implemented yet.

Could be, I'll come up with some test cases and write bugs.

Thanks,
Brian

Re: [FileAPI] Questions on using Blobs for img src and a href

[Brian Matthews (brmatthe)]

On 10/4/13 7:54 AM, Boris Zbarsky bzbar...@mit.edu wrote:

On 10/4/13 10:48 AM, Kyle Huey wrote:
 If a File object (which has a name) is used instead of a Blob I think we
 should treat it as if something like Content-Disposition:
 filename=$file.name http://file.name was specified in an HTTP
 request.

Gecko does, because a bunch of servers send it.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=272541

And we support it by treating it identically to Content-Disposition:
inline; filename=whatever.  Which is how I believe named Blobs should
be handled.

I'd agree, but they don't seem to be now (I think, I need to do some
testing). I'll come up with a test case and write some bugs if necessary.

Thanks,
Brian

Re: [FileAPI] Revisiting Deflate/Compression

[pira...@gmail.com]

I agree, the available libraries that currently exists not only are
slow compared to native code (I don't know of anyone that use the
trick used on the demos scene of canvas.getasbytestring() ) and to
speed up things they use webworkers, so they are difficult to use from
file:// scheme pages.

2013/7/13 Charles Pritchard ch...@jumis.com:
 We've had a few conversations pop up about exposing deflate/inflate to the
 webapps environment.
 Years of them (more recently May 2013).

 Packaging a zip file is very simple in JS, it's just the inflate/deflate
 code that's a trudge.
 We all know the benefits of compressing JSON and XML over the pipe.

 I'd like to see deflate exposed through FileReader.
 For example: reader.readAsArrayBuffer(blob, {deflate: true});

 Inflate semantics could be similar:
 reader.readAsArrayBuffer(blob, {inflate: true});

 Being that blob is synchronous, it seems like extending the constructor
 would only be reasonable in the context of a worker:
 new Blob([my easily compressed string], {deflate: true});

 Jonas already outlined some of the reasons not to pursue this:
 inflate/deflate can be performed in JS, JS is reasonably fast...

 In practice, JS is significantly slower than the browser's own native code,
 native code is already available in existing browsers, there are very few
 deflate/inflate JS libraries available, and including them has costs in
 size, loading time and licensing. As a consequence, web app authors are
 simply not using deflate when appropriate. We can easily remedy that by
 exposing deflate and inflate through these existing APIs.

 If there is push-back on extending Blob, I'm content with simply getting
 FileReader to support inflate/deflate.

 -Charles








-- 
Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix.
– Linus Tordvals, creador del sistema operativo Linux

Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object

[Arun Ranganathan]

On Sep 11, 2012, at 1:07 AM, Cameron McCormack wrote:

 Arun Ranganathan:
 I've pinged heycam to see if this is a proper use of the sequence type.  I'm 
 not sure it allows for such a variation in parameters.
 
 I agree with Boris, it makes sense to use sequence here.  Whenever you just 
 want to take a list of values in an operation argument, and you don't want to 
 keep a reference to a platform array object, you should use a sequence.


Done. http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob


-- A*

Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object

[Cameron McCormack]

Arun Ranganathan:

I've pinged heycam to see if this is a proper use of the sequence type.  I'm 
not sure it allows for such a variation in parameters.


I agree with Boris, it makes sense to use sequence here.  Whenever you 
just want to take a list of values in an operation argument, and you 
don't want to keep a reference to a platform array object, you should 
use a sequence.


But I also agree with Glenn that if you did use T[], and the 
implementation knows that it will never use the temporary platform array 
object that gets created when converting the (for example) JS Array 
object, it should be able to skip the actual platform array object creation.

Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object

[Boris Zbarsky]

On 9/9/12 12:13 PM, Glenn Maynard wrote:

In particular, a Blob represents immutable binary data.  That means
that it has to copy the input anyway.  Given that, it doesn't make
sense to pass the input by reference if the caller _does_ happen to
have an WebIDL array object.

That doesn't mean it copies the array itself, though.


That's true, but in most cases (certainly the ones where a JavaScript 
array will be passed in) that would happen anyway.



(Though both ways, this seems like an implementation detail


It's not quite.


I'd expect a mature binding system to let you annotate implementations to say
things like make a copy for me instead of passing it in by reference
and don't make a copy even though WebIDL requires it, because we
fulfill that requirement as a side-effect.)


Those are both incredibly fragile.  Consider some other random spec that 
has IDL like this.


  interface Foo {
// Returns the argument passed to the constructor
(ArrayBuffer or ArrayBufferView or Blob or DOMString)[]
  getInitData();
  };
  Blob implements Foo;

Now suddenly your annotation is a bug.

So in practice binding systems aren't particularly likely to implement 
such annotations because of the increased fragility they introduce.  The 
whole point of having IDL for bindings is to _reduce_ fragility


The upshot is that there are practical drawbacks (slowing down the 
common use case, as far as I can tell) and at best theoretical benefits 
(since nothing actually _produces_ platform arrays of the above union!).


By the way, note that if something produces a DOMString[] and you pass 
_that_ to a blob constructor as currently defined, then what will happen 
per spec is that the input will be converted to a sequenceDOMString 
and then a new platform array object will be created and the sequence 
copied into it.  So you'll still get passing by value, not by reference. 
 The only way to get passing by reference is if you're given a T[] 
where T exactly matches your array element type.


Basically, platform arrays are only useful if you both produce and 
consume them in the same interface, as far as I can tell...


-Boris

Re: [FileAPI] blob: protocol need a content-length header

[Arun Ranganathan]

Benjamin,

I filed the following:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18548

I think we should add Content-Length.

-- A*

On Aug 12, 2012, at 5:41 PM, Benjamin BERNARD wrote:

 I build de demo script (for firefox) here : 
 http://experiments.benvii.com/blob_content_length/
 You will also notice that the player's load event isn't called.
 
 Content-Length should be added to firefox (maybe open a ticket on 
 https://bugzilla.mozilla.org/) but it should also be recommended in the 
 section 11.7.3. Request and Response Headers of the spec.
 
 Thanks for responding.
 
 Benjamin BERNARD
 
 
 Le 12/08/2012 21:23, Jonas Sicking a écrit :
 On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD
 benjamin.bern...@benvii.com  wrote:
 Hi,
 I was developing an offline music web App when I discover that is no
 Content-length header specified here :
 http://www.w3.org/TR/FileAPI/#ProtocolExamples
 So when you play an audio/video file stored as a blob (under a blob URI)
 it's considered by the player as streaming content which means you can't get
 the duration of a song for instance (it has an infinite duration). I think
 it might be the consequence of not providing a content-length header.
 
 I experienced it using Firefox I heard Internet Explorer already provide
 this header.
 
 Moreover, I don't understand why there is no content-length header
 recommended in the spec because when you use URL.createObjectURL(blob), blob
 has a finished size (correct me if I'm wrong). So a content-length header
 should also be provided and recommended in the spec.
 Yes, I agree, we should have a content-length header similar to the
 content-type header.
 
 In Gecko things are a bit complicated because we don't have headers on
 anything but http channels. But we do have the concept of a length of
 a response for all channels so that should take care of it. Not sure
 off the top of my head why it doesn't. Filing a bug with an example
 would be great.
 
 / Jonas
 

Re: [FileAPI] blob: protocol need a content-length header

[Jonas Sicking]

On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD
benjamin.bern...@benvii.com wrote:
 Hi,
 I was developing an offline music web App when I discover that is no
 Content-length header specified here :
 http://www.w3.org/TR/FileAPI/#ProtocolExamples
 So when you play an audio/video file stored as a blob (under a blob URI)
 it's considered by the player as streaming content which means you can't get
 the duration of a song for instance (it has an infinite duration). I think
 it might be the consequence of not providing a content-length header.

 I experienced it using Firefox I heard Internet Explorer already provide
 this header.

 Moreover, I don't understand why there is no content-length header
 recommended in the spec because when you use URL.createObjectURL(blob), blob
 has a finished size (correct me if I'm wrong). So a content-length header
 should also be provided and recommended in the spec.

Yes, I agree, we should have a content-length header similar to the
content-type header.

In Gecko things are a bit complicated because we don't have headers on
anything but http channels. But we do have the concept of a length of
a response for all channels so that should take care of it. Not sure
off the top of my head why it doesn't. Filing a bug with an example
would be great.

/ Jonas

Re: [FileAPI] File.slice spec bug

[Andy Hou]

Hi,

It looks like IE10 supports File.slice() using the new spec.

Is it safe to use the new File.slice() spec, or should IE be using a vendor
prefix like Firefox and Chrome are currently doing.

Thanks,
Andy

Re: [FileAPI] createObjectURL isReusable proposal

[Robert O'Callahan]

On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch wrote:
  Anything's possible, but I think the pain here would far outweigh the
  benefits. There would be some really hard questions to answer, too (e.g.
  what would innerHTML return? If you copied such an image from a
  contentEditable section and pasted it lower down the same section, would
  it still have the image?).

 We could define that it returns an empty src attribute, which would
 break the copy/paste example. That's the same behavior you'd get with
 someone revoking the URL upon load anyway.


That's what I want to do when assigning a MediaStream to a media element's
src DOM attribute.
https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html
It seems to me to be the least bad option.

Having DOM state that's not reflected in the serialized DOM (or copied by
cloneNode()) is not good, but it's not new either. Form elements, canvases,
and media elements already have similar issues.

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others? [Matthew 5:43-47]

Re: [FileAPI] createObjectURL isReusable proposal

[Bronislav Klučka]

On 27.3.2012 11:43, Robert O'Callahan wrote:

On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking jo...@sicking.cc wrote:

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch
mailto:i...@hixie.ch wrote:
 Anything's possible, but I think the pain here would far
outweigh the
 benefits. There would be some really hard questions to answer,
too (e.g.
 what would innerHTML return? If you copied such an image from a
 contentEditable section and pasted it lower down the same
section, would
 it still have the image?).

We could define that it returns an empty src attribute, which would
break the copy/paste example. That's the same behavior you'd get with
someone revoking the URL upon load anyway.


That's what I want to do when assigning a MediaStream to a media 
element's src DOM attribute.

https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html
It seems to me to be the least bad option.

Having DOM state that's not reflected in the serialized DOM (or copied 
by cloneNode()) is not good, but it's not new either. Form elements, 
canvases, and media elements already have similar issues.
Which does not mean, that  it does not matter... And the issue is 
different here, because all canvases behave the same, all forms behave 
the same, but here some images copies would produce actual image 
(http://) some would not (blob://).
It would be much better to actually copy the Blob URL in src attribute 
and let it be dereferenced (it would either be succesfull or not, but 
it's based on programmer's design)


Brona

Re: [FileAPI] Deterministic release of Blob proposal

[Anne van Kesteren]

On Thu, 08 Mar 2012 00:58:02 +0100, Feras Moussa fer...@microsoft.com  
wrote:

In the case where close was called on a Blob that is being used in a
pending request, then the request should be canceled. The expected
result is the same as if abort() was called.


It seems very weird that invoking close() on Blob would invoke abort() on  
XMLHttpRequest. Would it not be better to not set the close flag until it  
is no longer in use?



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [FileAPI] Deterministic release of Blob proposal

[Glenn Maynard]

On Wed, Mar 7, 2012 at 5:58 PM, Feras Moussa fer...@microsoft.com wrote:

 In the case where close was called on a Blob that is being used in a
 pending request, then the request should be canceled. The expected
 result is the same as if abort() was called.


This would complicate every API that uses Blobs.  APIs should just make a
copy of the underlying data.  It minimizes the effects on other APIs and
makes the behavior consistently understandable.  In the case of XHR2, the
only change you'd need to make to that API, I think, would be for send() to
say if *data* is a *neutered* object, throw an exception in step 3 of
send().  The rest is already dealt with, since XHR2 already makes a copy
(Let the request entity body be the raw data represented by data.).

It simply means that any time you pass a Blob to a native API, the Blob is
implicitly sliced to create an independent (shallow, of course) copy before
it's used or stashed for later use.

That way, APIs never have to deal with blobs being released out from
underneath them, which could complicate things significantly (eg. you might
be accessing the blob's data from an asynchronous section).

 var a = new Image();
  a.onerror = function() { console.log(Oh no, my parent was neutered!);
 }; a.src = URL.createObjectURL(blob); blob.close();
 
  Is that error going to hit?
 I documented this in my proposal, but in this case the URI would have
 been minted prior to calling close. The Blob URI would still resolve
 until it has been revoked, so in your example onerror would not be hit
 due to calling close.


I do think this is what should happen, because createObjectURL would create
a copy of blob.  It seems a bit inconsistent with what your proposal,
though (if blob.close() always releases the underlying data, to the point
of aborting asynchronous XHR, then it should do so if it has associated
URLs, too).

-- 
Glenn Maynard

Re: [FileAPI] Deterministic release of Blob proposal

[Anne van Kesteren]

On Wed, 07 Mar 2012 02:12:39 +0100, Feras Moussa fer...@microsoft.com  
wrote:

xhr.send(blob);
blob.close(); // method name TBD


In our implementation, this case would fail. We think this is reasonable  
because the
need for having a close() method is to allow deterministic release of  
the resource.


Reasonable or not, would fail is not something we can put in a standard.  
What happens exactly? What if a connection is established and data is  
being transmitted already?



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Kenneth Russell]

On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote:
 On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote:

  You can always call close() yourself, but Blob.close() should use the
  neuter mechanism already there, not make up a new one.

 Blobs aren't transferable, there is no existing mechanism that applies
 to them. Adding a blob.close() method is independent of making blob's
 transferable, the former is not prerequisite on the latter.


 There is an existing mechanism for closing objects.  It's called
 neutering.  Blob.close should use the same terminology, whether or not the
 object is a Transferable.

 On Tue, Mar 6, 2012 at 4:25 PM, Kenneth Russell k...@google.com wrote:

 I would be hesitant to impose a close() method on all future
 Transferable types.


 Why?  All Transferable types must define how to neuter objects; all close()
 does is trigger it.

 I don't think adding one to ArrayBuffer would be a
 bad idea but I think that ideally it wouldn't be necessary. On memory
 constrained devices, it would still be more efficient to re-use large
 ArrayBuffers rather than close them and allocate new ones.


 That's often not possible, when the ArrayBuffer is returned to you from an
 API (eg. XHR2).

 This sounds like a good idea. As you pointed out offline, a key
 difference between Blobs and ArrayBuffers is that Blobs are always
 immutable. It isn't necessary to define Transferable semantics for
 Blobs in order to post them efficiently, but it was essential for
 ArrayBuffers.


 No new semantics need to be defined; the semantics of Transferable are
 defined by postMessage and are the same for all transferable objects.
 That's already done.  The only thing that needs to be defined is how to
 neuter an object, which is what Blob.close() has to define anyway.

 Using Transferable for Blob will allow Blobs, ArrayBuffers, and any future
 large, structured clonable objects to all be released with the same
 mechanisms: either pass them in the transfer argument to a postMessage
 call, or use the consistent, identical close() method inherited from
 Transferable.  This allows developers to think of the transfer list as a
 list of objects which won't be needed after the postMessage call.  It
 doesn't matter that the underlying optimizations are different; the visible
 side-effects are identical (the object can no longer be accessed).

Closing an object, and neutering it because it was transferred to a
different owner, are different concepts. It's already been
demonstrated that Blobs, being read-only, do not need to be
transferred in order to send them efficiently from one owner to
another. It's also been demonstrated that Blobs can be resource
intensive and that an explicit closing mechanism is needed.

I believe that we should fix the immediate problem and add a close()
method to Blob. I'm not in favor of adding a similar method to
ArrayBuffer at this time and therefore not to Transferable. There is a
high-level goal to keep the typed array specification as minimal as
possible, and having Transferable support leak in to the public
methods of the interfaces contradicts that goal.

-Ken

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Eric U]

On Wed, Mar 7, 2012 at 11:38 AM, Kenneth Russell k...@google.com wrote:
 On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote:
 On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote:

  You can always call close() yourself, but Blob.close() should use the
  neuter mechanism already there, not make up a new one.

 Blobs aren't transferable, there is no existing mechanism that applies
 to them. Adding a blob.close() method is independent of making blob's
 transferable, the former is not prerequisite on the latter.


 There is an existing mechanism for closing objects.  It's called
 neutering.  Blob.close should use the same terminology, whether or not the
 object is a Transferable.

 On Tue, Mar 6, 2012 at 4:25 PM, Kenneth Russell k...@google.com wrote:

 I would be hesitant to impose a close() method on all future
 Transferable types.


 Why?  All Transferable types must define how to neuter objects; all close()
 does is trigger it.

 I don't think adding one to ArrayBuffer would be a
 bad idea but I think that ideally it wouldn't be necessary. On memory
 constrained devices, it would still be more efficient to re-use large
 ArrayBuffers rather than close them and allocate new ones.


 That's often not possible, when the ArrayBuffer is returned to you from an
 API (eg. XHR2).

 This sounds like a good idea. As you pointed out offline, a key
 difference between Blobs and ArrayBuffers is that Blobs are always
 immutable. It isn't necessary to define Transferable semantics for
 Blobs in order to post them efficiently, but it was essential for
 ArrayBuffers.


 No new semantics need to be defined; the semantics of Transferable are
 defined by postMessage and are the same for all transferable objects.
 That's already done.  The only thing that needs to be defined is how to
 neuter an object, which is what Blob.close() has to define anyway.

 Using Transferable for Blob will allow Blobs, ArrayBuffers, and any future
 large, structured clonable objects to all be released with the same
 mechanisms: either pass them in the transfer argument to a postMessage
 call, or use the consistent, identical close() method inherited from
 Transferable.  This allows developers to think of the transfer list as a
 list of objects which won't be needed after the postMessage call.  It
 doesn't matter that the underlying optimizations are different; the visible
 side-effects are identical (the object can no longer be accessed).

 Closing an object, and neutering it because it was transferred to a
 different owner, are different concepts. It's already been
 demonstrated that Blobs, being read-only, do not need to be
 transferred in order to send them efficiently from one owner to
 another. It's also been demonstrated that Blobs can be resource
 intensive and that an explicit closing mechanism is needed.

 I believe that we should fix the immediate problem and add a close()
 method to Blob. I'm not in favor of adding a similar method to
 ArrayBuffer at this time and therefore not to Transferable. There is a
 high-level goal to keep the typed array specification as minimal as
 possible, and having Transferable support leak in to the public
 methods of the interfaces contradicts that goal.

This makes sense to me.  Blob needs close independent of whether it's
in Transferable, and Blob has no need to be Transferable, so let's not
mix the two.

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Charles Pritchard]

On Mar 7, 2012, at 11:38 AM, Kenneth Russell k...@google.com wrote:

 On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote:
 On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote:
 
 You can always call close() yourself, but Blob.close() should use the
 neuter mechanism already there, not make up a new one.
 
 Blobs aren't transferable, there is no existing mechanism that applies
 to them. Adding a blob.close() method is independent of making blob's
 transferable, the former is not prerequisite on the latter.
 
 
 There is an existing mechanism for closing objects.  It's called
 neutering.  Blob.close should use the same terminology, whether or not the
 object is a Transferable.
 
 On Tue, Mar 6, 2012 at 4:25 PM, Kenneth Russell k...@google.com wrote:
 
 I would be hesitant to impose a close() method on all future
 Transferable types.
 
 
 Why?  All Transferable types must define how to neuter objects; all close()
 does is trigger it.
 
 I don't think adding one to ArrayBuffer would be a
 bad idea but I think that ideally it wouldn't be necessary. On memory
 constrained devices, it would still be more efficient to re-use large
 ArrayBuffers rather than close them and allocate new ones.
 
 
 That's often not possible, when the ArrayBuffer is returned to you from an
 API (eg. XHR2).
 
 This sounds like a good idea. As you pointed out offline, a key
 difference between Blobs and ArrayBuffers is that Blobs are always
 immutable. It isn't necessary to define Transferable semantics for
 Blobs in order to post them efficiently, but it was essential for
 ArrayBuffers.
 
 
 No new semantics need to be defined; the semantics of Transferable are
 defined by postMessage and are the same for all transferable objects.
 That's already done.  The only thing that needs to be defined is how to
 neuter an object, which is what Blob.close() has to define anyway.
 
 Using Transferable for Blob will allow Blobs, ArrayBuffers, and any future
 large, structured clonable objects to all be released with the same
 mechanisms: either pass them in the transfer argument to a postMessage
 call, or use the consistent, identical close() method inherited from
 Transferable.  This allows developers to think of the transfer list as a
 list of objects which won't be needed after the postMessage call.  It
 doesn't matter that the underlying optimizations are different; the visible
 side-effects are identical (the object can no longer be accessed).
 
 Closing an object, and neutering it because it was transferred to a
 different owner, are different concepts. It's already been
 demonstrated that Blobs, being read-only, do not need to be
 transferred in order to send them efficiently from one owner to
 another. It's also been demonstrated that Blobs can be resource
 intensive and that an explicit closing mechanism is needed.
 
 I believe that we should fix the immediate problem and add a close()
 method to Blob. I'm not in favor of adding a similar method to
 ArrayBuffer at this time and therefore not to Transferable. There is a
 high-level goal to keep the typed array specification as minimal as
 possible, and having Transferable support leak in to the public
 methods of the interfaces contradicts that goal.

I think there's broad enough consensus amongst vendors to table the discussion 
about adding close to Transferable.

Would you please let me know why ypu believe ArrayBuffer should not have a 
close method?

I would like some clarity here. The Typed Array spec would not be cluttered by 
the addition of a simple close method.

I work much more with ArrayBuffer than Blob. I suspect others will too as they 
progress with more advanced and resource intensive applications.

What is the use-case distinction between close of immutable blob and close of a 
mutable buffer?

-Charles

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Greg Billock]

On Tue, Mar 6, 2012 at 1:18 PM, Kenneth Russell k...@google.com wrote:
 On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock gbill...@google.com wrote:
 On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard ch...@jumis.com wrote:
 On 3/5/2012 5:56 PM, Glenn Maynard wrote:

 On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com wrote:

 Do you see old behavior working something like the following?


 var blob = new Blob(my new big blob);
 var keepBlob = blob.slice(); destination.postMessage(blob, '*', [blob]);
 // is try/catch needed here?


 You don't need to do that.  If you don't want postMessage to transfer the
 blob, then simply don't include it in the transfer parameter, and it'll
 perform a normal structured clone.  postMessage behaves this way in part for
 backwards-compatibility: so exactly in cases like this, we can make Blob
 implement Transferable without breaking existing code.

 See http://dev.w3.org/html5/postmsg/#posting-messages and similar
 postMessage APIs.


 Web Intents won't have a transfer map argument.
 http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#widl-Intent-data

 For the Web Intents structured cloning algorithm, Web Intents would be
 inserting into step 3:
     If input is a Transferable object, add it to the transfer map.
 http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#internal-structured-cloning-algorithm

 Then Web Intents would move the first section of the structured cloning
 algorithm to follow the internal cloning algorithm section, swapping their
 order.
 http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data

 That's my understanding.

 We've been discussing the merits of this approach vs using a transfer
 array argument. There's a lot to like about this alternative -- it
 conserves arguments and looks simpler than the transfer map, as well
 as not having the headaches of whether you can do (null, [port]) or
 (port, [port]) and concerns like that.

 The advantage of using the transfer map param is that it is more
 contiguous with existing practice. We'd kind of hoped that this
 particular debate was finalized before we got to the point of needing
 to make a decision, so we bluffed and left it out of the web intents
 spec draft. :-) At this point, I'm leaning toward needing to add a
 transfer map parameter, and then dealing with that alongside other
 uses, given the state of thinking on Transferables support and the
 need to make this pretty consistent across structure clone
 invocations.

 I do think that complexity might be better solved by the type system
 (i.e. a new Transferable(ArrayBuffer)), which would require a
 different developer mechanic to set up clone vs transfer, but would
 relieve complexity in the invocation of structured clone itself:
 transferables could just always transfer transparently. I don't know
 if, given current practice with MessagePort, that kind of solution is
 available.

 A change like this would be feasible as long as it doesn't break
 compatibility. In other words, the current Transferable array would
 still need to be supported, but Transferable instances (or perhaps
 instances of some other type) wrapping another Transferable object
 would also express the intent.

 The current API for Transferable and postMessage was informed by the
 realization that the previous sequenceMessagePort argument to
 postMessage was essentially already expressing the Transferable
 concept.

 I'm not familiar with the Web Intents API, but at first glance it
 seems feasible to overload the constructor, postResult and postFailure
 methods to support passing a sequenceTransferable as the last
 argument. This would make the API look more like postMessage and avoid
 adding more transfer semantics. Is that possible?

Yes. That's our current plan.

-Greg

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Kenneth Russell]

On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchard ch...@jumis.com wrote:

 On Mar 7, 2012, at 11:38 AM, Kenneth Russell k...@google.com wrote:

 On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote:
 On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote:

 You can always call close() yourself, but Blob.close() should use the
 neuter mechanism already there, not make up a new one.

 Blobs aren't transferable, there is no existing mechanism that applies
 to them. Adding a blob.close() method is independent of making blob's
 transferable, the former is not prerequisite on the latter.


 There is an existing mechanism for closing objects.  It's called
 neutering.  Blob.close should use the same terminology, whether or not the
 object is a Transferable.

 On Tue, Mar 6, 2012 at 4:25 PM, Kenneth Russell k...@google.com wrote:

 I would be hesitant to impose a close() method on all future
 Transferable types.


 Why?  All Transferable types must define how to neuter objects; all close()
 does is trigger it.

 I don't think adding one to ArrayBuffer would be a
 bad idea but I think that ideally it wouldn't be necessary. On memory
 constrained devices, it would still be more efficient to re-use large
 ArrayBuffers rather than close them and allocate new ones.


 That's often not possible, when the ArrayBuffer is returned to you from an
 API (eg. XHR2).

 This sounds like a good idea. As you pointed out offline, a key
 difference between Blobs and ArrayBuffers is that Blobs are always
 immutable. It isn't necessary to define Transferable semantics for
 Blobs in order to post them efficiently, but it was essential for
 ArrayBuffers.


 No new semantics need to be defined; the semantics of Transferable are
 defined by postMessage and are the same for all transferable objects.
 That's already done.  The only thing that needs to be defined is how to
 neuter an object, which is what Blob.close() has to define anyway.

 Using Transferable for Blob will allow Blobs, ArrayBuffers, and any future
 large, structured clonable objects to all be released with the same
 mechanisms: either pass them in the transfer argument to a postMessage
 call, or use the consistent, identical close() method inherited from
 Transferable.  This allows developers to think of the transfer list as a
 list of objects which won't be needed after the postMessage call.  It
 doesn't matter that the underlying optimizations are different; the visible
 side-effects are identical (the object can no longer be accessed).

 Closing an object, and neutering it because it was transferred to a
 different owner, are different concepts. It's already been
 demonstrated that Blobs, being read-only, do not need to be
 transferred in order to send them efficiently from one owner to
 another. It's also been demonstrated that Blobs can be resource
 intensive and that an explicit closing mechanism is needed.

 I believe that we should fix the immediate problem and add a close()
 method to Blob. I'm not in favor of adding a similar method to
 ArrayBuffer at this time and therefore not to Transferable. There is a
 high-level goal to keep the typed array specification as minimal as
 possible, and having Transferable support leak in to the public
 methods of the interfaces contradicts that goal.

 I think there's broad enough consensus amongst vendors to table the 
 discussion about adding close to Transferable.

 Would you please let me know why ypu believe ArrayBuffer should not have a 
 close method?

 I would like some clarity here. The Typed Array spec would not be cluttered 
 by the addition of a simple close method.

It's certainly a matter of opinion -- but while it's only the addition
of one method, it changes typed arrays' semantics to be much closer to
manual memory allocation than they currently are. It would be a
further divergence in behavior from ordinary ECMAScript arrays.

The TC39 working group, I have heard, is incorporating typed arrays
into the language specification, and for this reason I believe extreme
care is warranted when adding more functionality to the typed array
spec. The spec can certainly move forward, but personally I'd like to
check with TC39 on semantic changes like this one. That's the
rationale behind my statement above about preferring not to add this
method at this time.

-Ken


 I work much more with ArrayBuffer than Blob. I suspect others will too as 
 they progress with more advanced and resource intensive applications.

 What is the use-case distinction between close of immutable blob and close of 
 a mutable buffer?

 -Charles

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Charles Pritchard]

On 3/7/12 12:34 PM, Kenneth Russell wrote:

On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchardch...@jumis.com  wrote:

On Mar 7, 2012, at 11:38 AM, Kenneth Russellk...@google.com  wrote:


I believe that we should fix the immediate problem and add a close()
method to Blob. I'm not in favor of adding a similar method to
ArrayBuffer at this time and therefore not to Transferable. There is a
high-level goal to keep the typed array specification as minimal as
possible, and having Transferable support leak in to the public
methods of the interfaces contradicts that goal.

I think there's broad enough consensus amongst vendors to table the discussion 
about adding close to Transferable.

Would you please let me know why ypu believe ArrayBuffer should not have a 
close method?

I would like some clarity here. The Typed Array spec would not be cluttered by 
the addition of a simple close method.

It's certainly a matter of opinion -- but while it's only the addition
of one method, it changes typed arrays' semantics to be much closer to
manual memory allocation than they currently are. It would be a
further divergence in behavior from ordinary ECMAScript arrays.

The TC39 working group, I have heard, is incorporating typed arrays
into the language specification, and for this reason I believe extreme
care is warranted when adding more functionality to the typed array
spec. The spec can certainly move forward, but personally I'd like to
check with TC39 on semantic changes like this one. That's the
rationale behind my statement above about preferring not to add this
method at this time.


Searching through the net tells me that this has been a rumor for years.

I agree with taking extreme care -- so let's isolate one more bit of 
information:


Is ArrayBuffer being proposed for TC39 incorporation, or is it only the 
Typed Arrays? The idea here is to alter ArrayBuffer, an object which can 
be neutered via transfer map. It seems a waste to have to create a 
Worker to close down buffer views.


Will TC39 have anything to say about the neuter concept and/or Web 
Messaging?



Again, I'm bringing this up for the same practical experience that 
Blob.close() was brought up. I do appreciate that read/write allocation 
is a separate semantic from write-once/read-many allocation.


I certainly don't want to derail the introduction of Typed Array into 
TC39. I don't want to sit back for two years either, while the 
ArrayBuffer object is in limbo.


If necessary, I'll do some of the nasty test work of creating a worker 
simply to destroy buffers, and report back on it.

var worker = new Worker('trash.js');
worker.postMessage(null,[bufferToClose]);
worker.close();
vs.
bufferToClose.close();



-Charles

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Kenneth Russell]

On Wed, Mar 7, 2012 at 1:00 PM, Charles Pritchard ch...@jumis.com wrote:
 On 3/7/12 12:34 PM, Kenneth Russell wrote:

 On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchardch...@jumis.com
  wrote:

 On Mar 7, 2012, at 11:38 AM, Kenneth Russellk...@google.com  wrote:

 I believe that we should fix the immediate problem and add a close()
 method to Blob. I'm not in favor of adding a similar method to
 ArrayBuffer at this time and therefore not to Transferable. There is a
 high-level goal to keep the typed array specification as minimal as
 possible, and having Transferable support leak in to the public
 methods of the interfaces contradicts that goal.

 I think there's broad enough consensus amongst vendors to table the
 discussion about adding close to Transferable.

 Would you please let me know why ypu believe ArrayBuffer should not have
 a close method?

 I would like some clarity here. The Typed Array spec would not be
 cluttered by the addition of a simple close method.

 It's certainly a matter of opinion -- but while it's only the addition
 of one method, it changes typed arrays' semantics to be much closer to
 manual memory allocation than they currently are. It would be a
 further divergence in behavior from ordinary ECMAScript arrays.

 The TC39 working group, I have heard, is incorporating typed arrays
 into the language specification, and for this reason I believe extreme
 care is warranted when adding more functionality to the typed array
 spec. The spec can certainly move forward, but personally I'd like to
 check with TC39 on semantic changes like this one. That's the
 rationale behind my statement above about preferring not to add this
 method at this time.


 Searching through the net tells me that this has been a rumor for years.

Regardless of rumors I have talked to multiple members of TC39 who
have clearly stated it is being incorporated into ES6 Harmony.

 I agree with taking extreme care -- so let's isolate one more bit of
 information:

 Is ArrayBuffer being proposed for TC39 incorporation, or is it only the
 Typed Arrays? The idea here is to alter ArrayBuffer, an object which can be
 neutered via transfer map. It seems a waste to have to create a Worker to
 close down buffer views.

Both ArrayBuffer and the typed array views will be incorporated.

 Will TC39 have anything to say about the neuter concept and/or Web
 Messaging?

This is an excellent question and one which I've also posed to TC39. I
don't see how the language spec could reference these concepts. I'm
guessing that this is an area that TC39 hasn't yet figured out,
either.

 Again, I'm bringing this up for the same practical experience that
 Blob.close() was brought up. I do appreciate that read/write allocation is a
 separate semantic from write-once/read-many allocation.

 I certainly don't want to derail the introduction of Typed Array into TC39.
 I don't want to sit back for two years either, while the ArrayBuffer object
 is in limbo.

Understood and appreciated.

 If necessary, I'll do some of the nasty test work of creating a worker
 simply to destroy buffers, and report back on it.
 var worker = new Worker('trash.js');
 worker.postMessage(null,[bufferToClose]);
 worker.close();
 vs.
 bufferToClose.close();

I doubt that that will work. Garbage collection will still need to run
in the worker's JavaScript context in order for the transferred
ArrayBuffer to be cleaned up, and I doubt that happens eagerly upon
shutdown of the worker. Would be happy to be proven wrong.

If you prototype adding ArrayBuffer.close() in your open source
browser of choice and report back on significant efficiency
improvements in a real-world use case, that would be valuable
feedback.

-Ken

Re: [FileAPI] Deterministic release of Blob proposal

[Eric U]

On Tue, Mar 6, 2012 at 5:12 PM, Feras Moussa fer...@microsoft.com wrote:
 From: Arun Ranganathan [mailto:aranganat...@mozilla.com]
 Sent: Tuesday, March 06, 2012 1:27 PM
 To: Feras Moussa
 Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson; Anne van Kesteren
 Subject: Re: [FileAPI] Deterministic release of Blob proposal

 Feras,

 In practice, I think this is important enough and manageable enough to 
 include in the spec., and I'm willing to slow the train down if necessary, 
 but I'd like to understand a few things first.  Below:
 
  At TPAC we discussed the ability to deterministically close blobs with a 
  few
  others.
   
  As we’ve discussed in the createObjectURL thread[1], a Blob may represent
  an expensive resource (eg. expensive in terms of memory, battery, or disk
  space). At present there is no way for an application to deterministically
  release the resource backing the Blob. Instead, an application must rely on
  the resource being cleaned up through a non-deterministic garbage collector
  once all references have been released. We have found that not having a way
  to deterministically release the resource causes a performance impact for a
  certain class of applications, and is especially important for mobile 
  applications
  or devices with more limited resources.
 
  In particular, we’ve seen this become a problem for media intensive 
  applications
  which interact with a large number of expensive blobs. For example, a 
  gallery
  application may want to cycle through displaying many large images 
  downloaded
  through websockets, and without a deterministic way to immediately release
  the reference to each image Blob, can easily begin to consume vast amounts 
  of
  resources before the garbage collector is executed.
   
  To address this issue, we propose that a close method be added to the Blob
  interface.
  When called, the close method should release the underlying resource of the
  Blob, and future operations on the Blob will return a new error, a 
  ClosedError.
  This allows an application to signal when it's finished using the Blob.
 

 Do you agree that Transferable
 (http://dev.w3.org/html5/spec/Overview.html#transferable-objects) seems to 
 be what
 we're looking for, and that Blob should implement Transferable?

 Transferable addresses the use case of copying across threads, and neuters 
 the source
 object (though honestly, the word neuter makes me wince -- naming is a 
 problem on the
 web).  We can have a more generic method on Transferable that serves our 
 purpose here,
 rather than *.close(), and Blob can avail of that.  This is something we can 
 work out with HTML,
 and might be the right thing to do for the platform (although this creates 
 something to think
 about for MessagePort and for ArrayBuffer, which also implement 
 Transferable).

 I agree with your changes, but am confused by some edge cases:
 To support this change, the following changes in the File API spec are 
 needed:
 
 * In section 6 (The Blob Interface)
  - Addition of a close method. When called, the close method releases the
 underlying resource of the Blob. Close renders the blob invalid, and further
 operations such as URL.createObjectURL or the FileReader read methods on
 the closed blob will fail and return a ClosedError.  If there are any 
 non-revoked
 URLs to the Blob, these URLs will continue to resolve until they have been
 revoked.
  - For the slice method, state that the returned Blob is a new Blob with 
its own
 lifetime semantics – calling close on the new Blob is independent of 
 calling close
 on the original Blob.

 *In section 8 (The FIleReader Interface)
 - State the FileReader reads directly over the given Blob, and not a copy 
 with
 an independent lifetime.

 * In section 10 (Errors and Exceptions)
 - Addition of a ClosedError. If the File or Blob has had the close method 
 called,
 then for asynchronous read methods the error attribute MUST return a
 “ClosedError” DOMError and synchronous read methods MUST throw a
 ClosedError exception.

 * In section 11.8 (Creating and Revoking a Blob URI)
 - For createObjectURL – If this method is called with a closed Blob 
 argument,
 then user agents must throw a ClosedError exception.

 Similarly to how slice() clones the initial Blob to return one with its own
 independent lifetime, the same notion will be needed in other APIs which
 conceptually clone the data – namely FormData, any place the Structured 
 Clone
 Algorithm is used, and BlobBuilder.
 Similarly to how FileReader must act directly on the Blob’s data, the same 
 notion
 will be needed in other APIs which must act on the data - namely XHR.send 
 and
 WebSocket. These APIs will need to throw an error if called on a Blob that 
 was
 closed and the resources are released.

 So Blob.slice() already presumes a new Blob, but I can certainly make this 
 clearer.
 And I agree with the changes above, including the addition

RE: [FileAPI] Deterministic release of Blob proposal

[Feras Moussa]

 Then let's try this again.

 var a = new Image();
 a.onerror = function() { console.log(Oh no, my parent was neutered!); }; 
 a.src = URL.createObjectURL(blob); blob.close();

 Is that error going to hit?
I documented this in my proposal, but in this case the URI would have 
been minted prior to calling close. The Blob URI would still resolve 
until it has been revoked, so in your example onerror would not be hit 
due to calling close.

 var a = new Worker('#');
 a.postMessage(blob);
 blob.close();

 Is that blob going to make it to the worker?
SCA runs synchronously (so that subsequent changes to mutable values 
in the object don't impact the message) so the blob will have been 
cloned prior to close. 
The above would work as expected.

RE: [FileAPI] Deterministic release of Blob proposal

[Feras Moussa]

 -Original Message-
 From: Anne van Kesteren [mailto:ann...@opera.com] 
 Sent: Wednesday, March 07, 2012 12:49 AM
 To: Arun Ranganathan; Feras Moussa
 Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson
 Subject: Re: [FileAPI] Deterministic release of Blob proposal

 On Wed, 07 Mar 2012 02:12:39 +0100, Feras Moussa fer...@microsoft.com
 wrote:
  xhr.send(blob);
  blob.close(); // method name TBD
 
  In our implementation, this case would fail. We think this is 
  reasonable because the need for having a close() method is to allow 
  deterministic release of the resource.

 Reasonable or not, would fail is not something we can put in a standard.  
 What happens exactly? What if a connection is established and data is being 
 transmitted already?
In the case where close was called on a Blob that is being used in a 
pending request, then the request should be canceled. The expected 
result is the same as if abort() was called.

Re: [FileAPI] Deterministic release of Blob proposal

[Charles Pritchard]

On 3/7/12 3:56 PM, Feras Moussa wrote:

Then let's try this again.

var a = new Image();
a.onerror = function() { console.log(Oh no, my parent was neutered!); }; 
a.src = URL.createObjectURL(blob); blob.close();

Is that error going to hit?

until it has been revoked, so in your example onerror would not be hit
due to calling close.

var a = new Worker('#');
a.postMessage(blob);
blob.close();

The above would work as expected.


Well that all makes sense; so speaking for myself, I'm still confused 
about this one thing:



 xhr.send(blob);
 blob.close(); // method name TBD



 In our implementation, this case would fail. We think this is reasonable 
because the



So you want this to be a situation where we monitor progress events of 
XHR before releasing the blob?
It seems feasible to monitor the upload progress, but it is a little 
awkward.


-Charles

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Greg Billock]

On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard ch...@jumis.com wrote:
 On 3/5/2012 5:56 PM, Glenn Maynard wrote:

 On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com wrote:

 Do you see old behavior working something like the following?


 var blob = new Blob(my new big blob);
 var keepBlob = blob.slice(); destination.postMessage(blob, '*', [blob]);
 // is try/catch needed here?


 You don't need to do that.  If you don't want postMessage to transfer the
 blob, then simply don't include it in the transfer parameter, and it'll
 perform a normal structured clone.  postMessage behaves this way in part for
 backwards-compatibility: so exactly in cases like this, we can make Blob
 implement Transferable without breaking existing code.

 See http://dev.w3.org/html5/postmsg/#posting-messages and similar
 postMessage APIs.


 Web Intents won't have a transfer map argument.
 http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#widl-Intent-data

 For the Web Intents structured cloning algorithm, Web Intents would be
 inserting into step 3:
     If input is a Transferable object, add it to the transfer map.
 http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#internal-structured-cloning-algorithm

 Then Web Intents would move the first section of the structured cloning
 algorithm to follow the internal cloning algorithm section, swapping their
 order.
 http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data

 That's my understanding.

We've been discussing the merits of this approach vs using a transfer
array argument. There's a lot to like about this alternative -- it
conserves arguments and looks simpler than the transfer map, as well
as not having the headaches of whether you can do (null, [port]) or
(port, [port]) and concerns like that.

The advantage of using the transfer map param is that it is more
contiguous with existing practice. We'd kind of hoped that this
particular debate was finalized before we got to the point of needing
to make a decision, so we bluffed and left it out of the web intents
spec draft. :-) At this point, I'm leaning toward needing to add a
transfer map parameter, and then dealing with that alongside other
uses, given the state of thinking on Transferables support and the
need to make this pretty consistent across structure clone
invocations.

I do think that complexity might be better solved by the type system
(i.e. a new Transferable(ArrayBuffer)), which would require a
different developer mechanic to set up clone vs transfer, but would
relieve complexity in the invocation of structured clone itself:
transferables could just always transfer transparently. I don't know
if, given current practice with MessagePort, that kind of solution is
available.

 Something like this may be necessary if Blob were a Transferable:
 var keepBlob = blob.slice();
 var intent = new Intent(-x-my-intent, blob);
 navigator.startActivity(intent, callback);

 And we might have an error on postMessage stashing it in the transfer
 array if it's not a Transferable on an older browser.




 Example of how easy the neutered concept applies to Transferrable:

 var blob = new Blob(my big blob);
 blob.close();


 I like the idea of having Blob implement Transferrable and adding close to
 the Transferrable interface.
 File.close could have a better relationship with the cache and/or locks on
 data.


 Some history on Transferrable and structured clones:

 Note: MessagePort does have a close method and is currently the only
 Transferrable mentioned in WHATWG:
 http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable-objects

 ArrayBuffer is widely implemented. It was the second item to implement
 Transferrable:
 http://www.khronos.org/registry/typedarray/specs/latest/#9

 Subsequently, ImageData adopted Uint8ClampedArray for one of its properties,
 adopting TypedArrays:
 http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#imagedata

 This has lead to some instability in the structured clone algorithm for
 ImageData as the typed array object for ImageData is read-only.
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=13800

 ArrayBuffer is still in a strawman state.

 -Charles

Re: [FileAPI] Deterministic release of Blob proposal

[Eric U]

After a brief internal discussion, we like the idea over in Chrome-land.
Let's make sure that we carefully spec out the edge cases, though.
See below for some.

On Fri, Mar 2, 2012 at 4:54 PM, Feras Moussa fer...@microsoft.com wrote:
 At TPAC we discussed the ability to deterministically close blobs with a few

 others.



 As we’ve discussed in the createObjectURL thread[1], a Blob may represent

 an expensive resource (eg. expensive in terms of memory, battery, or disk

 space). At present there is no way for an application to deterministically

 release the resource backing the Blob. Instead, an application must rely on

 the resource being cleaned up through a non-deterministic garbage collector

 once all references have been released. We have found that not having a way

 to deterministically release the resource causes a performance impact for a

 certain class of applications, and is especially important for mobile
 applications

 or devices with more limited resources.



 In particular, we’ve seen this become a problem for media intensive
 applications

 which interact with a large number of expensive blobs. For example, a
 gallery

 application may want to cycle through displaying many large images
 downloaded

 through websockets, and without a deterministic way to immediately release

 the reference to each image Blob, can easily begin to consume vast amounts
 of

 resources before the garbage collector is executed.



 To address this issue, we propose that a close method be added to the Blob

 interface.

 When called, the close method should release the underlying resource of the

 Blob, and future operations on the Blob will return a new error, a
 ClosedError.

 This allows an application to signal when it's finished using the Blob.



 To support this change, the following changes in the File API spec are
 needed:



 * In section 6 (The Blob Interface)

   - Addition of a close method. When called, the close method releases the

 underlying resource of the Blob. Close renders the blob invalid, and further

 operations such as URL.createObjectURL or the FileReader read methods on

 the closed blob will fail and return a ClosedError.  If there are any
 non-revoked

 URLs to the Blob, these URLs will continue to resolve until they have been

 revoked.

   - For the slice method, state that the returned Blob is a new Blob with
 its own

 lifetime semantics – calling close on the new Blob is independent of calling
 close

 on the original Blob.



 *In section 8 (The FIleReader Interface)

 - State the FileReader reads directly over the given Blob, and not a copy
 with

 an independent lifetime.



 * In section 10 (Errors and Exceptions)

 - Addition of a ClosedError. If the File or Blob has had the close method
 called,

 then for asynchronous read methods the error attribute MUST return a

 “ClosedError” DOMError and synchronous read methods MUST throw a

 ClosedError exception.



 * In section 11.8 (Creating and Revoking a Blob URI)

 - For createObjectURL – If this method is called with a closed Blob
 argument,

 then user agents must throw a ClosedError exception.



 Similarly to how slice() clones the initial Blob to return one with its own

 independent lifetime, the same notion will be needed in other APIs which

 conceptually clone the data – namely FormData, any place the Structured
 Clone

 Algorithm is used, and BlobBuilder.

What about:

XHR.send(blob);
blob.close();

or

iframe.src = createObjectURL(blob);
blob.close();

In the second example, if we say that the iframe does copy the blob,
does that mean that closing the blob doesn't automatically revoke the
URL, since it points at the new copy?  Or does it point at the old
copy and fail?

 Similarly to how FileReader must act directly on the Blob’s data, the same
 notion

 will be needed in other APIs which must act on the data - namely XHR.send
 and

 WebSocket. These APIs will need to throw an error if called on a Blob that
 was

 closed and the resources are released.



 We’ve recently implemented this in experimental builds and have seen
 measurable

 performance improvements.



 The feedback we heard from our discussions with others at TPAC regarding our

 proposal to add a close() method to the Blob interface was that objects in
 the web

 platform potentially backed by expensive resources should have a
 deterministic

 way to be released.



 Thanks,

 Feras



 [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1499.html

Re: [FileAPI] Deterministic release of Blob proposal

[David Levin]

It seems like this may be setting up a pattern for other dom objects which
are large (like video/audio).

When applied in this context, is close still a good verb for them?

  video.close();

dave

PS I'm trying to not bikeshed too badly by avoiding a new name suggestion
and allowing for the fact that close may be an ok name.


On Tue, Mar 6, 2012 at 12:29 PM, Eric U er...@google.com wrote:

 After a brief internal discussion, we like the idea over in Chrome-land.
 Let's make sure that we carefully spec out the edge cases, though.
 See below for some.

 On Fri, Mar 2, 2012 at 4:54 PM, Feras Moussa fer...@microsoft.com wrote:
  At TPAC we discussed the ability to deterministically close blobs with a
 few
 
  others.
 
 
 
  As we’ve discussed in the createObjectURL thread[1], a Blob may represent
 
  an expensive resource (eg. expensive in terms of memory, battery, or disk
 
  space). At present there is no way for an application to
 deterministically
 
  release the resource backing the Blob. Instead, an application must rely
 on
 
  the resource being cleaned up through a non-deterministic garbage
 collector
 
  once all references have been released. We have found that not having a
 way
 
  to deterministically release the resource causes a performance impact
 for a
 
  certain class of applications, and is especially important for mobile
  applications
 
  or devices with more limited resources.
 
 
 
  In particular, we’ve seen this become a problem for media intensive
  applications
 
  which interact with a large number of expensive blobs. For example, a
  gallery
 
  application may want to cycle through displaying many large images
  downloaded
 
  through websockets, and without a deterministic way to immediately
 release
 
  the reference to each image Blob, can easily begin to consume vast
 amounts
  of
 
  resources before the garbage collector is executed.
 
 
 
  To address this issue, we propose that a close method be added to the
 Blob
 
  interface.
 
  When called, the close method should release the underlying resource of
 the
 
  Blob, and future operations on the Blob will return a new error, a
  ClosedError.
 
  This allows an application to signal when it's finished using the Blob.
 
 
 
  To support this change, the following changes in the File API spec are
  needed:
 
 
 
  * In section 6 (The Blob Interface)
 
- Addition of a close method. When called, the close method releases
 the
 
  underlying resource of the Blob. Close renders the blob invalid, and
 further
 
  operations such as URL.createObjectURL or the FileReader read methods on
 
  the closed blob will fail and return a ClosedError.  If there are any
  non-revoked
 
  URLs to the Blob, these URLs will continue to resolve until they have
 been
 
  revoked.
 
- For the slice method, state that the returned Blob is a new Blob with
  its own
 
  lifetime semantics – calling close on the new Blob is independent of
 calling
  close
 
  on the original Blob.
 
 
 
  *In section 8 (The FIleReader Interface)
 
  - State the FileReader reads directly over the given Blob, and not a copy
  with
 
  an independent lifetime.
 
 
 
  * In section 10 (Errors and Exceptions)
 
  - Addition of a ClosedError. If the File or Blob has had the close method
  called,
 
  then for asynchronous read methods the error attribute MUST return a
 
  “ClosedError” DOMError and synchronous read methods MUST throw a
 
  ClosedError exception.
 
 
 
  * In section 11.8 (Creating and Revoking a Blob URI)
 
  - For createObjectURL – If this method is called with a closed Blob
  argument,
 
  then user agents must throw a ClosedError exception.
 
 
 
  Similarly to how slice() clones the initial Blob to return one with its
 own
 
  independent lifetime, the same notion will be needed in other APIs which
 
  conceptually clone the data – namely FormData, any place the Structured
  Clone
 
  Algorithm is used, and BlobBuilder.

 What about:

XHR.send(blob);
blob.close();

 or

iframe.src = createObjectURL(blob);
blob.close();

 In the second example, if we say that the iframe does copy the blob,
 does that mean that closing the blob doesn't automatically revoke the
 URL, since it points at the new copy?  Or does it point at the old
 copy and fail?

  Similarly to how FileReader must act directly on the Blob’s data, the
 same
  notion
 
  will be needed in other APIs which must act on the data - namely XHR.send
  and
 
  WebSocket. These APIs will need to throw an error if called on a Blob
 that
  was
 
  closed and the resources are released.
 
 
 
  We’ve recently implemented this in experimental builds and have seen
  measurable
 
  performance improvements.
 
 
 
  The feedback we heard from our discussions with others at TPAC regarding
 our
 
  proposal to add a close() method to the Blob interface was that objects
 in
  the web
 
  platform potentially backed by expensive resources should have a
  deterministic
 

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Kenneth Russell]

On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock gbill...@google.com wrote:
 On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard ch...@jumis.com wrote:
 On 3/5/2012 5:56 PM, Glenn Maynard wrote:

 On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com wrote:

 Do you see old behavior working something like the following?


 var blob = new Blob(my new big blob);
 var keepBlob = blob.slice(); destination.postMessage(blob, '*', [blob]);
 // is try/catch needed here?


 You don't need to do that.  If you don't want postMessage to transfer the
 blob, then simply don't include it in the transfer parameter, and it'll
 perform a normal structured clone.  postMessage behaves this way in part for
 backwards-compatibility: so exactly in cases like this, we can make Blob
 implement Transferable without breaking existing code.

 See http://dev.w3.org/html5/postmsg/#posting-messages and similar
 postMessage APIs.


 Web Intents won't have a transfer map argument.
 http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#widl-Intent-data

 For the Web Intents structured cloning algorithm, Web Intents would be
 inserting into step 3:
     If input is a Transferable object, add it to the transfer map.
 http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#internal-structured-cloning-algorithm

 Then Web Intents would move the first section of the structured cloning
 algorithm to follow the internal cloning algorithm section, swapping their
 order.
 http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data

 That's my understanding.

 We've been discussing the merits of this approach vs using a transfer
 array argument. There's a lot to like about this alternative -- it
 conserves arguments and looks simpler than the transfer map, as well
 as not having the headaches of whether you can do (null, [port]) or
 (port, [port]) and concerns like that.

 The advantage of using the transfer map param is that it is more
 contiguous with existing practice. We'd kind of hoped that this
 particular debate was finalized before we got to the point of needing
 to make a decision, so we bluffed and left it out of the web intents
 spec draft. :-) At this point, I'm leaning toward needing to add a
 transfer map parameter, and then dealing with that alongside other
 uses, given the state of thinking on Transferables support and the
 need to make this pretty consistent across structure clone
 invocations.

 I do think that complexity might be better solved by the type system
 (i.e. a new Transferable(ArrayBuffer)), which would require a
 different developer mechanic to set up clone vs transfer, but would
 relieve complexity in the invocation of structured clone itself:
 transferables could just always transfer transparently. I don't know
 if, given current practice with MessagePort, that kind of solution is
 available.

A change like this would be feasible as long as it doesn't break
compatibility. In other words, the current Transferable array would
still need to be supported, but Transferable instances (or perhaps
instances of some other type) wrapping another Transferable object
would also express the intent.

The current API for Transferable and postMessage was informed by the
realization that the previous sequenceMessagePort argument to
postMessage was essentially already expressing the Transferable
concept.

I'm not familiar with the Web Intents API, but at first glance it
seems feasible to overload the constructor, postResult and postFailure
methods to support passing a sequenceTransferable as the last
argument. This would make the API look more like postMessage and avoid
adding more transfer semantics. Is that possible?


 Something like this may be necessary if Blob were a Transferable:
 var keepBlob = blob.slice();
 var intent = new Intent(-x-my-intent, blob);
 navigator.startActivity(intent, callback);

 And we might have an error on postMessage stashing it in the transfer
 array if it's not a Transferable on an older browser.




 Example of how easy the neutered concept applies to Transferrable:

 var blob = new Blob(my big blob);
 blob.close();


 I like the idea of having Blob implement Transferrable and adding close to
 the Transferrable interface.
 File.close could have a better relationship with the cache and/or locks on
 data.

I'm not sure that adding close() to Transferable is a good idea. Not
all Transferable types may want to support that explicit operation.
What about adding close() to Blob, and having the neutering operation
on Blob be defined to call close() on it?

-Ken


 Some history on Transferrable and structured clones:

 Note: MessagePort does have a close method and is currently the only
 Transferrable mentioned in WHATWG:
 http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable-objects

 ArrayBuffer is widely implemented. It was the second item to implement
 

Re: [FileAPI] Deterministic release of Blob proposal

[Arun Ranganathan]

Feras, 

In practice, I think this is important enough and manageable enough to include 
in the spec., and I'm willing to slow the train down if necessary, but I'd like 
to understand a few things first. Below: 

- Original Message -

 At TPAC we discussed the ability to deterministically close blobs
 with a few
 others.

 As we’ve discussed in the createObjectURL thread[1], a Blob may
 represent
 an expensive resource (eg. expensive in terms of memory, battery, or
 disk
 space). At present there is no way for an application to
 deterministically
 release the resource backing the Blob. Instead, an application must
 rely on
 the resource being cleaned up through a non-deterministic garbage
 collector
 once all references have been released. We have found that not having
 a way
 to deterministically release the resource causes a performance impact
 for a
 certain class of applications, and is especially important for mobile
 applications
 or devices with more limited resources.

 In particular, we’ve seen this become a problem for media intensive
 applications
 which interact with a large number of expensive blobs. For example, a
 gallery
 application may want to cycle through displaying many large images
 downloaded
 through websockets, and without a deterministic way to immediately
 release
 the reference to each image Blob, can easily begin to consume vast
 amounts of
 resources before the garbage collector is executed.

 To address this issue, we propose that a close method be added to the
 Blob
 interface.
 When called, the close method should release the underlying resource
 of the
 Blob, and future operations on the Blob will return a new erro r , a
 ClosedError.
 This allows an application to signal when it's finished using the
 Blob.

Do you agree that Transferable 
(http://dev.w3.org/html5/spec/Overview.html#transferable-objects) seems to be 
what we're looking for, and that Blob should implement Transferable? 

Transferable addresses the use case of copying across threads, and neuters 
the source object (though honestly, the word neuter makes me wince -- naming 
is a problem on the web). We can have a more generic method on Transferable 
that serves our purpose here, rather than *.close(), and Blob can avail of 
that. This is something we can work out with HTML, and might be the right thing 
to do for the platform (although this creates something to think about for 
MessagePort and for ArrayBuffer, which also implement Transferable). 

I agree with your changes, but am confused by some edge cases: 

 To support this change, the following changes in the File API spec
 are needed:

 * In section 6 (The Blob Interface)
 - Addition of a close method. When called, the close method releases
 the
 underlying resource of the Blob. Close renders the blob invalid, and
 further
 operations such as URL.createObjectURL or the FileReader read methods
 on
 the closed blob will fail and return a ClosedError. If there are any
 non-revoked
 URLs to the Blob, these URLs will continue to resolve until they have
 been
 revoked.
 - For the slice method, state that the returned Blob is a new Blob
 with its own
 lifetime semantics – calling close on the new Blob is independent of
 calling close
 on the original Blob.

 *In section 8 (The FIleReader Interface)
 - State the FileReader reads directly over the given Blob, and not a
 copy with
 an independent lifetime.

 * In section 10 (Errors and Exceptions)
 - Addition of a ClosedError. If the File or Blob has had the close
 method called,
 then for asynchronous read methods the error attribute MUST return a
 “ClosedError” DOMError and synchronous read methods MUST throw a
 ClosedError exception.

 * In section 11.8 (Creating and Revoking a Blob URI)
 - For createObjectURL – If this method is called with a closed Blob
 argument,
 then user agents must throw a ClosedError exception.

 Similarly to how slice() clones the initial Blob to return one with
 its own
 independent lifetime, the same notion will be needed in other APIs
 which
 conceptually clone the data – namely FormData, any place the
 Structured Clone
 Algorithm is used, and BlobBuilder.
 Similarly to how FileReader must act directly on the Blob’s data, the
 same notion
 will be needed in other APIs which must act on the data - namely
 XHR.send and
 WebSocket. These APIs will need to throw an error if called on a Blob
 that was
 closed and the resources are released.
So Blob.slice() already presumes a new Blob, but I can certainly make this 
clearer. And I agree with the changes above, including the addition of 
something liked ClosedError (though I suppose this is an important enough error 
+ exception to hash out with HTML and DOM4, and once again, the name is TBD). 

In your implementation, what happens exactly to Eric's edge cases, namely: 

xhr.send(blob); 
blob.close(); // method name TBD 

// AND 

frameRef.src = URL.createObjectURL(blob); 
blob.close() // method name TBD 

In my opinion, the 

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Arun Ranganathan]

Ken,

 I'm not sure that adding close() to Transferable is a good idea. Not
 all Transferable types may want to support that explicit operation.
 What about adding close() to Blob, and having the neutering operation
 on Blob be defined to call close() on it?


Specifically, you think this is not something ArrayBuffer should inherit?  If 
it's also a bad idea for MessagePort, then those are really our only two use 
cases of Transferable right now.  I'm happy to create something like a close() 
on Blob.

-- A*

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Michael Nordman]

Sounds like there's a good case for an explicit blob.close() method
independent of 'transferable'. Separately defining blobs to be
transferrable feels like an unneeded complexity. A caller wishing to
neuter after sending can explicit call .close() rather than relying on
more obscure artifacts of having also put the 'blob' in a
'transferrable' array.

On Tue, Mar 6, 2012 at 1:18 PM, Kenneth Russell k...@google.com wrote:
 On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock gbill...@google.com wrote:
 On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard ch...@jumis.com wrote:
 On 3/5/2012 5:56 PM, Glenn Maynard wrote:

 On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com wrote:

 Do you see old behavior working something like the following?


 var blob = new Blob(my new big blob);
 var keepBlob = blob.slice(); destination.postMessage(blob, '*', [blob]);
 // is try/catch needed here?


 You don't need to do that.  If you don't want postMessage to transfer the
 blob, then simply don't include it in the transfer parameter, and it'll
 perform a normal structured clone.  postMessage behaves this way in part for
 backwards-compatibility: so exactly in cases like this, we can make Blob
 implement Transferable without breaking existing code.

 See http://dev.w3.org/html5/postmsg/#posting-messages and similar
 postMessage APIs.


 Web Intents won't have a transfer map argument.
 http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#widl-Intent-data

 For the Web Intents structured cloning algorithm, Web Intents would be
 inserting into step 3:
     If input is a Transferable object, add it to the transfer map.
 http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#internal-structured-cloning-algorithm

 Then Web Intents would move the first section of the structured cloning
 algorithm to follow the internal cloning algorithm section, swapping their
 order.
 http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data

 That's my understanding.

 We've been discussing the merits of this approach vs using a transfer
 array argument. There's a lot to like about this alternative -- it
 conserves arguments and looks simpler than the transfer map, as well
 as not having the headaches of whether you can do (null, [port]) or
 (port, [port]) and concerns like that.

 The advantage of using the transfer map param is that it is more
 contiguous with existing practice. We'd kind of hoped that this
 particular debate was finalized before we got to the point of needing
 to make a decision, so we bluffed and left it out of the web intents
 spec draft. :-) At this point, I'm leaning toward needing to add a
 transfer map parameter, and then dealing with that alongside other
 uses, given the state of thinking on Transferables support and the
 need to make this pretty consistent across structure clone
 invocations.

 I do think that complexity might be better solved by the type system
 (i.e. a new Transferable(ArrayBuffer)), which would require a
 different developer mechanic to set up clone vs transfer, but would
 relieve complexity in the invocation of structured clone itself:
 transferables could just always transfer transparently. I don't know
 if, given current practice with MessagePort, that kind of solution is
 available.

 A change like this would be feasible as long as it doesn't break
 compatibility. In other words, the current Transferable array would
 still need to be supported, but Transferable instances (or perhaps
 instances of some other type) wrapping another Transferable object
 would also express the intent.

 The current API for Transferable and postMessage was informed by the
 realization that the previous sequenceMessagePort argument to
 postMessage was essentially already expressing the Transferable
 concept.

 I'm not familiar with the Web Intents API, but at first glance it
 seems feasible to overload the constructor, postResult and postFailure
 methods to support passing a sequenceTransferable as the last
 argument. This would make the API look more like postMessage and avoid
 adding more transfer semantics. Is that possible?


 Something like this may be necessary if Blob were a Transferable:
 var keepBlob = blob.slice();
 var intent = new Intent(-x-my-intent, blob);
 navigator.startActivity(intent, callback);

 And we might have an error on postMessage stashing it in the transfer
 array if it's not a Transferable on an older browser.




 Example of how easy the neutered concept applies to Transferrable:

 var blob = new Blob(my big blob);
 blob.close();


 I like the idea of having Blob implement Transferrable and adding close to
 the Transferrable interface.
 File.close could have a better relationship with the cache and/or locks on
 data.

 I'm not sure that adding close() to Transferable is a good idea. Not
 all Transferable types may want to support that explicit operation.
 What about adding 

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Glenn Maynard]

On Tue, Mar 6, 2012 at 3:18 PM, Kenneth Russell k...@google.com wrote:
 A change like this would be feasible as long as it doesn't break
 compatibility. In other words, the current Transferable array would
 still need to be supported, but Transferable instances (or perhaps
 instances of some other type) wrapping another Transferable object
 would also express the intent.

I don't like this, because it loses the invariant that structured clone is
a const operation by default.  That is, if you don't explicitly specify
objects in the transfer map, structured clone guarantees that the object
you pass in won't be modified, and that (as a corollary) you can create as
many structured clones as you want.  This always works:

function(obj)
{
thread1.postMessage(obj);
thread2.postMessage(obj);
thread3.postMessage(obj);
}

With the wrapper approach, it would no longer be guaranteed to work.

I'm not sure that adding close() to Transferable is a good idea. Not
 all Transferable types may want to support that explicit operation.
 What about adding close() to Blob, and having the neutering operation
 on Blob be defined to call close() on it?


When would you explicitly want to disallow manually neutering a
Transferable object?

The only case I can think where it's not obviously useful is MessagePort,
but I think that will be an exceptional case and that most Transferables
will want this method.  ArrayBuffer (currently the only other Transferable)
will, of course.

On Tue, Mar 6, 2012 at 3:34 PM, Michael Nordman micha...@google.com
 wrote:

 Separately defining blobs to be transferrable feels like an unneeded
 complexity. A caller wishing to
 neuter after sending can explicit call .close() rather than relying on
 more obscure artifacts of having also put the 'blob' in a
 'transferrable' array.


You can always call close() yourself, but Blob.close() should use the
neuter mechanism already there, not make up a new one.

-- 
Glenn Maynard

Re: [FileAPI] Deterministic release of Blob proposal

[Glenn Maynard]

(I wish people wouldn't split threads.)

On Tue, Mar 6, 2012 at 2:29 PM, Eric U er...@google.com wrote:

 What about:

XHR.send(blob);
blob.close();


This is the same as:

XHR.send(arrayBuffer);
postMessage({foo: arrayBuffer}, [arrayBuffer]);

which you can already do.  Both of these should always work, because send()
synchronously makes a (logical) copy of the underlying data:

If data is a ArrayBuffer
Let the request entity body be the raw data represented by data.
If data is a Blob
Let the request entity body be the raw data represented by data.

which happens before the call returns.


 or

iframe.src = createObjectURL(blob);
blob.close();

In the second example, if we say that the iframe does copy the blob,
 does that mean that closing the blob doesn't automatically revoke the
 URL, since it points at the new copy?  Or does it point at the old
 copy and fail?


Looking at this without involving iframe:

You could define object URLs as references to a new copy of the blob.  That
would mean that if the blob is neutered while object URLs still point at
it, a copy of the blob would have to be made by the UA even though it's
transferred.

Or, object URLs could be references to the blob itself.  That means that if
the blob is neutered, existing object URLs would be implicitly revoked.

I'd suggest the former: when a Blob is passed to native APIs, make a
(logical) copy of the Blob.  More generally, I'd recommend that all native
calls which accept a Blob, like createObjectURL, make a logical copy of the
data, like XHR.send does.  It's much easier to be consistent that way.


On Tue, Mar 6, 2012 at 3:27 PM, Arun Ranganathan aranganat...@mozilla.com
 wrote:

 although this creates something to think about for MessagePort and for
 ArrayBuffer, which also implement Transferable).


close() would be useful for ArrayBuffer, too.  It's not obviously useful
for MessagePort, but doesn't seem harmful for it to inherit it if it's not
a big implementation burden.  That's better than every single
implementation of Transferable having to define this itself.

-- 
Glenn Maynard

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Michael Nordman]

 Separately defining blobs to be transferrable feels like an unneeded
 complexity. A caller wishing to
 neuter after sending can explicit call .close() rather than relying on
 more obscure artifacts of having also put the 'blob' in a
 'transferrable' array.


 You can always call close() yourself, but Blob.close() should use the
 neuter mechanism already there, not make up a new one.

Blobs aren't transferable, there is no existing mechanism that applies
to them. Adding a blob.close() method is independent of making blob's
transferable, the former is not prerequisite on the latter.

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Kenneth Russell]

On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
 Ken,

 I'm not sure that adding close() to Transferable is a good idea. Not
 all Transferable types may want to support that explicit operation.
 What about adding close() to Blob, and having the neutering operation
 on Blob be defined to call close() on it?


 Specifically, you think this is not something ArrayBuffer should inherit?  If 
 it's also a bad idea for MessagePort, then those are really our only two use 
 cases of Transferable right now.  I'm happy to create something like a 
 close() on Blob.

MessagePort already defines a close() operation, so there's really no
question of whether its presence is a good or bad idea there. A
close() operation seems necessary in networking style APIs.

I would be hesitant to impose a close() method on all future
Transferable types. I don't think adding one to ArrayBuffer would be a
bad idea but I think that ideally it wouldn't be necessary. On memory
constrained devices, it would still be more efficient to re-use large
ArrayBuffers rather than close them and allocate new ones.


On Tue, Mar 6, 2012 at 1:34 PM, Michael Nordman micha...@google.com wrote:
 Sounds like there's a good case for an explicit blob.close() method
 independent of 'transferable'. Separately defining blobs to be
 transferrable feels like an unneeded complexity. A caller wishing to
 neuter after sending can explicit call .close() rather than relying on
 more obscure artifacts of having also put the 'blob' in a
 'transferrable' array.

This sounds like a good idea. As you pointed out offline, a key
difference between Blobs and ArrayBuffers is that Blobs are always
immutable. It isn't necessary to define Transferable semantics for
Blobs in order to post them efficiently, but it was essential for
ArrayBuffers.

-Ken

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Charles Pritchard]

On Mar 6, 2012, at 2:25 PM, Kenneth Russell k...@google.com wrote:

 On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan
 aranganat...@mozilla.com wrote:
 Ken,
 
 I'm not sure that adding close() to Transferable is a good idea. Not
 all Transferable types may want to support that explicit operation.
 What about adding close() to Blob, and having the neutering operation
 on Blob be defined to call close() on it?
 
 
 Specifically, you think this is not something ArrayBuffer should inherit?  
 If it's also a bad idea for MessagePort, then those are really our only two 
 use cases of Transferable right now.  I'm happy to create something like a 
 close() on Blob.
 
 MessagePort already defines a close() operation, so there's really no
 question of whether its presence is a good or bad idea there. A
 close() operation seems necessary in networking style APIs.
 
 I would be hesitant to impose a close() method on all future
 Transferable types. I don't think adding one to ArrayBuffer would be a
 bad idea but I think that ideally it wouldn't be necessary. On memory
 constrained devices, it would still be more efficient to re-use large
 ArrayBuffers rather than close them and allocate new ones.


By definition, Transferable objects can be neutered; we're talking about an 
explicit method for it. After that, it's up to implementers.

I prefer .close to .release. 

An ArrayBuffer using 12megs of ram is something I want to release ASAP on 
mobile.

.close would still allow for the optimization you're implying in memory mapping.





 
 
 On Tue, Mar 6, 2012 at 1:34 PM, Michael Nordman micha...@google.com wrote:
 Sounds like there's a good case for an explicit blob.close() method
 independent of 'transferable'. Separately defining blobs to be
 transferrable feels like an unneeded complexity. A caller wishing to
 neuter after sending can explicit call .close() rather than relying on
 more obscure artifacts of having also put the 'blob' in a
 'transferrable' array.
 
 This sounds like a good idea. As you pointed out offline, a key
 difference between Blobs and ArrayBuffers is that Blobs are always
 immutable. It isn't necessary to define Transferable semantics for
 Blobs in order to post them efficiently, but it was essential for
 ArrayBuffers.
 

Making Blob a Transferable may simplify the structured clone algorithm; Blob an 
File would no longer be explicitly listed. Adding close to Transferable would 
simplify three different objects -- ArrayBuffer, MessagePort and Blob. In 
theory anyway.

While Blob doesn't need the transfer map optimization, it may be helpful in the 
context of web intents postMessage as it would release the Blob references from 
one window, possibly making GC a little easier. That's just a guess... But this 
thread is about enhancing the process. Seems reasonable that this would be a 
side effect.

File.close() may have implementation side effects, such as releasing read locks 
on underlying files.

-Charles

RE: [FileAPI] Deterministic release of Blob proposal

[Feras Moussa]

 From: Arun Ranganathan [mailto:aranganat...@mozilla.com] 
 Sent: Tuesday, March 06, 2012 1:27 PM
 To: Feras Moussa
 Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson; Anne van Kesteren
 Subject: Re: [FileAPI] Deterministic release of Blob proposal

 Feras,

 In practice, I think this is important enough and manageable enough to 
 include in the spec., and I'm willing to slow the train down if necessary, 
 but I'd like to understand a few things first.  Below:
 
  At TPAC we discussed the ability to deterministically close blobs with a 
  few 
  others.
  
  As we’ve discussed in the createObjectURL thread[1], a Blob may represent 
  an expensive resource (eg. expensive in terms of memory, battery, or disk 
  space). At present there is no way for an application to deterministically 
  release the resource backing the Blob. Instead, an application must rely on 
  the resource being cleaned up through a non-deterministic garbage collector 
  once all references have been released. We have found that not having a way 
  to deterministically release the resource causes a performance impact for a 
  certain class of applications, and is especially important for mobile 
  applications 
  or devices with more limited resources.
  
  In particular, we’ve seen this become a problem for media intensive 
  applications 
  which interact with a large number of expensive blobs. For example, a 
  gallery 
  application may want to cycle through displaying many large images 
  downloaded 
  through websockets, and without a deterministic way to immediately release 
  the reference to each image Blob, can easily begin to consume vast amounts 
  of 
  resources before the garbage collector is executed. 
  
  To address this issue, we propose that a close method be added to the Blob 
  interface.
  When called, the close method should release the underlying resource of the 
  Blob, and future operations on the Blob will return a new error, a 
  ClosedError. 
  This allows an application to signal when it's finished using the Blob.
  

 Do you agree that Transferable 
 (http://dev.w3.org/html5/spec/Overview.html#transferable-objects) seems to be 
 what 
 we're looking for, and that Blob should implement Transferable?  

 Transferable addresses the use case of copying across threads, and neuters 
 the source 
 object (though honestly, the word neuter makes me wince -- naming is a 
 problem on the 
 web).  We can have a more generic method on Transferable that serves our 
 purpose here, 
 rather than *.close(), and Blob can avail of that.  This is something we can 
 work out with HTML, 
 and might be the right thing to do for the platform (although this creates 
 something to think 
 about for MessagePort and for ArrayBuffer, which also implement Transferable).

 I agree with your changes, but am confused by some edge cases:
 To support this change, the following changes in the File API spec are 
 needed:
 
 * In section 6 (The Blob Interface)
  - Addition of a close method. When called, the close method releases the 
 underlying resource of the Blob. Close renders the blob invalid, and further 
 operations such as URL.createObjectURL or the FileReader read methods on 
 the closed blob will fail and return a ClosedError.  If there are any 
 non-revoked 
 URLs to the Blob, these URLs will continue to resolve until they have been 
 revoked. 
  - For the slice method, state that the returned Blob is a new Blob with its 
own 
 lifetime semantics – calling close on the new Blob is independent of calling 
 close 
 on the original Blob.
 
 *In section 8 (The FIleReader Interface)
 - State the FileReader reads directly over the given Blob, and not a copy 
 with 
 an independent lifetime.
 
 * In section 10 (Errors and Exceptions)
 - Addition of a ClosedError. If the File or Blob has had the close method 
 called, 
 then for asynchronous read methods the error attribute MUST return a 
 “ClosedError” DOMError and synchronous read methods MUST throw a 
 ClosedError exception.
 
 * In section 11.8 (Creating and Revoking a Blob URI)
 - For createObjectURL – If this method is called with a closed Blob 
 argument, 
 then user agents must throw a ClosedError exception.
 
 Similarly to how slice() clones the initial Blob to return one with its own 
 independent lifetime, the same notion will be needed in other APIs which 
 conceptually clone the data – namely FormData, any place the Structured 
 Clone 
 Algorithm is used, and BlobBuilder.
 Similarly to how FileReader must act directly on the Blob’s data, the same 
 notion 
 will be needed in other APIs which must act on the data - namely XHR.send 
 and 
 WebSocket. These APIs will need to throw an error if called on a Blob that 
 was 
 closed and the resources are released.

 So Blob.slice() already presumes a new Blob, but I can certainly make this 
 clearer.  
 And I agree with the changes above, including the addition of something liked

RE: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Feras Moussa]

 -Original Message-
 From: Arun Ranganathan [mailto:aranganat...@mozilla.com]
 Sent: Tuesday, March 06, 2012 1:32 PM
 To: Kenneth Russell
 Cc: public-webapps@w3.org; Charles Pritchard; Glenn Maynard; Feras
 Moussa; Adrian Bateman; Greg Billock
 Subject: Re: Transferable and structured clones, was: Re: [FileAPI]
 Deterministic release of Blob proposal
 
 Ken,
 
  I'm not sure that adding close() to Transferable is a good idea. Not
  all Transferable types may want to support that explicit operation.
  What about adding close() to Blob, and having the neutering operation
  on Blob be defined to call close() on it?
 
 
 Specifically, you think this is not something ArrayBuffer should inherit?  If 
 it's
 also a bad idea for MessagePort, then those are really our only two use cases
 of Transferable right now.  I'm happy to create something like a close() on
 Blob.
 
 -- A*
We agree Blobs do not need to be transferrable, and thus it makes sense to have 
close directly on Blob, independent of being transferable.

Re: [FileAPI] Deterministic release of Blob proposal

[Charles Pritchard]

On 3/6/12 5:12 PM, Feras Moussa wrote:


  frameRef.src = URL.createObjectURL(blob);
  blob.close() // method name TBD

  In my opinion, the first (using xhr) should succeed.  In the second, 
frameRef.src works,
  but subsequent attempts to mint a Blob URI for the same 'blob' resource 
fail.  Does this
  hold true for you?

We agree that subsequent attempts to mint a blob URI for a blob that has been 
closed
should fail, and is what I tried to clarify in my comments in 'section 6'.
As an aside, the above example shows navigation to a Blob URI - this is not 
something we
Currently support or intend to support.



Then let's try this again.

var a = new Image();
a.onerror = function() { console.log(Oh no, my parent was neutered!); };
a.src = URL.createObjectURL(blob);
blob.close();

Is that error going to hit?

var a = new Worker('#');
a.postMessage(blob);
blob.close();

Is that blob going to make it to the worker?


-Charles

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Glenn Maynard]

On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote:

  You can always call close() yourself, but Blob.close() should use the
  neuter mechanism already there, not make up a new one.

 Blobs aren't transferable, there is no existing mechanism that applies
 to them. Adding a blob.close() method is independent of making blob's
 transferable, the former is not prerequisite on the latter.


There is an existing mechanism for closing objects.  It's called
neutering.  Blob.close should use the same terminology, whether or not
the object is a Transferable.

On Tue, Mar 6, 2012 at 4:25 PM, Kenneth Russell k...@google.com wrote:

 I would be hesitant to impose a close() method on all future
 Transferable types.


Why?  All Transferable types must define how to neuter objects; all close()
does is trigger it.

I don't think adding one to ArrayBuffer would be a
 bad idea but I think that ideally it wouldn't be necessary. On memory
 constrained devices, it would still be more efficient to re-use large
 ArrayBuffers rather than close them and allocate new ones.


That's often not possible, when the ArrayBuffer is returned to you from an
API (eg. XHR2).

 This sounds like a good idea. As you pointed out offline, a key
 difference between Blobs and ArrayBuffers is that Blobs are always
 immutable. It isn't necessary to define Transferable semantics for
 Blobs in order to post them efficiently, but it was essential for
 ArrayBuffers.


No new semantics need to be defined; the semantics of Transferable are
defined by postMessage and are the same for all transferable objects.
That's already done.  The only thing that needs to be defined is how to
neuter an object, which is what Blob.close() has to define anyway.

Using Transferable for Blob will allow Blobs, ArrayBuffers, and any future
large, structured clonable objects to all be released with the same
mechanisms: either pass them in the transfer argument to a postMessage
call, or use the consistent, identical close() method inherited from
Transferable.  This allows developers to think of the transfer list as a
list of objects which won't be needed after the postMessage call.  It
doesn't matter that the underlying optimizations are different; the visible
side-effects are identical (the object can no longer be accessed).

-- 
Glenn Maynard

Re: [FileAPI] Deterministic release of Blob proposal

[Arthur Barstow]

Feras - this seems kinda' late, especially since the two-week pre-LC 
comment period for File API ended Feb 24.


Is this a feature that can be postponed to v.next?

On 3/2/12 7:54 PM, ext Feras Moussa wrote:


At TPAC we discussed the ability to deterministically close blobs with 
a few


others.

As we’ve discussed in the createObjectURL thread[1], a Blob may represent

an expensive resource (eg. expensive in terms of memory, battery, or disk

space). At present there is no way for an application to 
deterministically


release the resource backing the Blob. Instead, an application must 
rely on


the resource being cleaned up through a non-deterministic garbage 
collector


once all references have been released. We have found that not having 
a way


to deterministically release the resource causes a performance impact 
for a


certain class of applications, and is especially important for mobile 
applications


or devices with more limited resources.

In particular, we’ve seen this become a problem for media intensive 
applications


which interact with a large number of expensive blobs. For example, a 
gallery


application may want to cycle through displaying many large images 
downloaded


through websockets, and without a deterministic way to immediately 
release


the reference to each image Blob, can easily begin to consume vast 
amounts of


resources before the garbage collector is executed.

To address this issue, we propose that a close method be added to the 
Blob


interface.

When called, the close method should release the underlying resource 
of the


Blob, and future operations on the Blob will return a new error, a 
ClosedError.


This allows an application to signal when it's finished using the Blob.

To support this change, the following changes in the File API spec are 
needed:


* In section 6 (The Blob Interface)

- Addition of a close method. When called, the close method releases the

underlying resource of the Blob. Close renders the blob invalid, and 
further


operations such as URL.createObjectURL or the FileReader read methods on

the closed blob will fail and return a ClosedError. If there are any 
non-revoked


URLs to the Blob, these URLs will continue to resolve until they have 
been


revoked.

- For the slice method, state that the returned Blob is a new Blob 
with its own


lifetime semantics – calling close on the new Blob is independent of 
calling close


on the original Blob.

*In section 8 (The FIleReader Interface)

- State the FileReader reads directly over the given Blob, and not a 
copy with


an independent lifetime.

* In section 10 (Errors and Exceptions)

- Addition of a ClosedError. If the File or Blob has had the close 
method called,


then for asynchronous read methods the error attribute MUST return a

“ClosedError” DOMError and synchronous read methods MUST throw a

ClosedError exception.

* In section 11.8 (Creating and Revoking a Blob URI)

- For createObjectURL – If this method is called with a closed Blob 
argument,


then user agents must throw a ClosedError exception.

Similarly to how slice() clones the initial Blob to return one with 
its own


independent lifetime, the same notion will be needed in other APIs which

conceptually clone the data – namely FormData, any place the 
Structured Clone


Algorithm is used, and BlobBuilder.

Similarly to how FileReader must act directly on the Blob’s data, the 
same notion


will be needed in other APIs which must act on the data - namely 
XHR.send and


WebSocket. These APIs will need to throw an error if called on a Blob 
that was


closed and the resources are released.

We’ve recently implemented this in experimental builds and have seen 
measurable


performance improvements.

The feedback we heard from our discussions with others at TPAC 
regarding our


proposal to add a close() method to the Blob interface was that 
objects in the web


platform potentially backed by expensive resources should have a 
deterministic


way to be released.

Thanks,

Feras

[1] 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1499.html

RE: [FileAPI] Deterministic release of Blob proposal

[Feras Moussa]

The feedback is implementation feedback that we have refined in the past few 
weeks as we've updated our implementation. 
We're happy with it to be treated as a LC comment, but we'd also give this 
feedback in CR too since in recent weeks we've found it to be a problem in apps 
which make extensive use of the APIs.

 -Original Message-
 From: Arthur Barstow [mailto:art.bars...@nokia.com]
 Sent: Monday, March 05, 2012 12:52 PM
 To: Feras Moussa; Arun Ranganathan; Jonas Sicking
 Cc: public-webapps@w3.org; Adrian Bateman
 Subject: Re: [FileAPI] Deterministic release of Blob proposal
 
 Feras - this seems kinda' late, especially since the two-week pre-LC comment
 period for File API ended Feb 24.
 
 Is this a feature that can be postponed to v.next?
 
 On 3/2/12 7:54 PM, ext Feras Moussa wrote:
 
  At TPAC we discussed the ability to deterministically close blobs with
  a few
 
  others.
 
  As we've discussed in the createObjectURL thread[1], a Blob may
  represent
 
  an expensive resource (eg. expensive in terms of memory, battery, or
  disk
 
  space). At present there is no way for an application to
  deterministically
 
  release the resource backing the Blob. Instead, an application must
  rely on
 
  the resource being cleaned up through a non-deterministic garbage
  collector
 
  once all references have been released. We have found that not having
  a way
 
  to deterministically release the resource causes a performance impact
  for a
 
  certain class of applications, and is especially important for mobile
  applications
 
  or devices with more limited resources.
 
  In particular, we've seen this become a problem for media intensive
  applications
 
  which interact with a large number of expensive blobs. For example, a
  gallery
 
  application may want to cycle through displaying many large images
  downloaded
 
  through websockets, and without a deterministic way to immediately
  release
 
  the reference to each image Blob, can easily begin to consume vast
  amounts of
 
  resources before the garbage collector is executed.
 
  To address this issue, we propose that a close method be added to the
  Blob
 
  interface.
 
  When called, the close method should release the underlying resource
  of the
 
  Blob, and future operations on the Blob will return a new error, a
  ClosedError.
 
  This allows an application to signal when it's finished using the Blob.
 
  To support this change, the following changes in the File API spec are
  needed:
 
  * In section 6 (The Blob Interface)
 
  - Addition of a close method. When called, the close method releases
  the
 
  underlying resource of the Blob. Close renders the blob invalid, and
  further
 
  operations such as URL.createObjectURL or the FileReader read methods
  on
 
  the closed blob will fail and return a ClosedError. If there are any
  non-revoked
 
  URLs to the Blob, these URLs will continue to resolve until they have
  been
 
  revoked.
 
  - For the slice method, state that the returned Blob is a new Blob
  with its own
 
  lifetime semantics - calling close on the new Blob is independent of
  calling close
 
  on the original Blob.
 
  *In section 8 (The FIleReader Interface)
 
  - State the FileReader reads directly over the given Blob, and not a
  copy with
 
  an independent lifetime.
 
  * In section 10 (Errors and Exceptions)
 
  - Addition of a ClosedError. If the File or Blob has had the close
  method called,
 
  then for asynchronous read methods the error attribute MUST return a
 
  ClosedError DOMError and synchronous read methods MUST throw a
 
  ClosedError exception.
 
  * In section 11.8 (Creating and Revoking a Blob URI)
 
  - For createObjectURL - If this method is called with a closed Blob
  argument,
 
  then user agents must throw a ClosedError exception.
 
  Similarly to how slice() clones the initial Blob to return one with
  its own
 
  independent lifetime, the same notion will be needed in other APIs
  which
 
  conceptually clone the data - namely FormData, any place the
  Structured Clone
 
  Algorithm is used, and BlobBuilder.
 
  Similarly to how FileReader must act directly on the Blob's data, the
  same notion
 
  will be needed in other APIs which must act on the data - namely
  XHR.send and
 
  WebSocket. These APIs will need to throw an error if called on a Blob
  that was
 
  closed and the resources are released.
 
  We've recently implemented this in experimental builds and have seen
  measurable
 
  performance improvements.
 
  The feedback we heard from our discussions with others at TPAC
  regarding our
 
  proposal to add a close() method to the Blob interface was that
  objects in the web
 
  platform potentially backed by expensive resources should have a
  deterministic
 
  way to be released.
 
  Thanks,
 
  Feras
 
  [1]
  http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1499.htm
  l
 

Re: [FileAPI] Deterministic release of Blob proposal

[Glenn Maynard]

On Fri, Mar 2, 2012 at 6:54 PM, Feras Moussa fer...@microsoft.com wrote:

 To address this issue, we propose that a close method be added to the Blob
 

 interface.

 When called, the close method should release the underlying resource of
 the 

 Blob, and future operations on the Blob will return a new error, a
 ClosedError. 

 This allows an application to signal when it's finished using the Blob.


This is exactly like the neuter concept, defined at
http://dev.w3.org/html5/spec/common-dom-interfaces.html#transferable-objects.
I recommend using it.  Make Blob a Transferable, and have close() neuter
the object.  The rest of this wouldn't change much, except you'd say if
the object has been neutered (or has the neutered flag set, or however
it's defined) instead of if the close method has been called.

Originally, I think it was assumed that Blobs don't need to be
Transferable, because they're immutable, which means you don't
(necessarily) need to make a copy when transferring them between threads.
That was only considering the cost of copying the Blob, though, not the
costs of delayed GC that you're talking about here, so I think transferable
Blobs do make sense.

Also, the close() method should probably go on Transferable (with a name
less likely to clash, eg. neuter), instead of as a one-off on Blob.  If
it's useful for Blob, it's probably useful for ArrayBuffer and all other
future Transferables as well.

-- 
Glenn Maynard

Re: [FileAPI] Deterministic release of Blob proposal

[Charles Pritchard]

On 3/5/2012 3:59 PM, Glenn Maynard wrote:
On Fri, Mar 2, 2012 at 6:54 PM, Feras Moussa fer...@microsoft.com 
mailto:fer...@microsoft.com wrote:


To address this issue, we propose that a close method be added to
the Blob

interface.

When called, the close method should release the underlying
resource of the

Blob, and future operations on the Blob will return a new error, a
ClosedError.

This allows an application to signal when it's finished using the
Blob.


This is exactly like the neuter concept, defined at 
http://dev.w3.org/html5/spec/common-dom-interfaces.html#transferable-objects.  
I recommend using it.  Make Blob a Transferable, and have close() 
neuter the object.  The rest of this wouldn't change much, except 
you'd say if the object has been neutered (or has the neutered flag 
set, or however it's defined) instead of if the close method has 
been called.


Originally, I think it was assumed that Blobs don't need to be 
Transferable, because they're immutable, which means you don't 
(necessarily) need to make a copy when transferring them between 
threads.  That was only considering the cost of copying the Blob, 
though, not the costs of delayed GC that you're talking about here, so 
I think transferable Blobs do make sense.


Also, the close() method should probably go on Transferable (with a 
name less likely to clash, eg. neuter), instead of as a one-off on 
Blob.  If it's useful for Blob, it's probably useful for ArrayBuffer 
and all other future Transferables as well.




Glenn,

Do you see old behavior working something like the following?

var blob = new Blob(my new big blob);
var keepBlob = blob.slice();
destination.postMessage(blob, '*', [blob]); // is try/catch needed here?
blob = keepBlob; // keeping a copy of my blob still in thread.

Sorry to cover too many angles: if Blob is Transferable, then it'll 
neuter; so if we do want a local copy, we'd use slice ahead of time to 
keep it.
And we might have an error on postMessage stashing it in the transfer 
array if it's not a Transferable on an older browser.

The new behavior is pretty easy.
var blob = new Blob(my big blob);
blob.close(); // My blob has been neutered before it could procreate.

-Charles

Re: [FileAPI] Deterministic release of Blob proposal

[Glenn Maynard]

On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com wrote:

  Do you see old behavior working something like the following?


 var blob = new Blob(my new big blob);
 var keepBlob = blob.slice();
 destination.postMessage(blob, '*', [blob]); // is try/catch needed here?
 blob = keepBlob; // keeping a copy of my blob still in thread.

Sorry to cover too many angles: if Blob is Transferable, then it'll neuter;
 so if we do want a local copy, we'd use slice ahead of time to keep it.


You don't need to do that.  If you don't want postMessage to transfer the
blob, then simply don't include it in the transfer parameter, and it'll
perform a normal structured clone.  postMessage behaves this way in part
for backwards-compatibility: so exactly in cases like this, we can make
Blob implement Transferable without breaking existing code.

See http://dev.w3.org/html5/postmsg/#posting-messages and similar
postMessage APIs.


 And we might have an error on postMessage stashing it in the transfer
 array if it's not a Transferable on an older browser.


It'll throw TypeError, which you'll need to handle if you need to support
older browsers.

The new behavior is pretty easy.
 var blob = new Blob(my big blob);
 blob.close(); // My blob has been neutered before it could procreate.


Sorry, I'm not really sure what you're trying to say.  This still works
when using the neutered concept; it just uses an existing mechanism, and
allows transfers.

-- 
Glenn Maynard

Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

[Charles Pritchard]

On 3/5/2012 5:56 PM, Glenn Maynard wrote:
On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com 
mailto:ch...@jumis.com wrote:


Do you see old behavior working something like the following?


var blob = new Blob(my new big blob);
var keepBlob = blob.slice(); destination.postMessage(blob, '*',
[blob]); // is try/catch needed here?


You don't need to do that.  If you don't want postMessage to transfer 
the blob, then simply don't include it in the transfer parameter, and 
it'll perform a normal structured clone.  postMessage behaves this way 
in part for backwards-compatibility: so exactly in cases like this, we 
can make Blob implement Transferable without breaking existing code.


See http://dev.w3.org/html5/postmsg/#posting-messages and similar 
postMessage APIs.


Web Intents won't have a transfer map argument.
http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#widl-Intent-data

For the Web Intents structured cloning algorithm, Web Intents would be 
inserting into step 3:

If input is a Transferable object, add it to the transfer map.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#internal-structured-cloning-algorithm

Then Web Intents would move the first section of the structured cloning 
algorithm to follow the internal cloning algorithm section, swapping 
their order.

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data

That's my understanding.

Something like this may be necessary if Blob were a Transferable:
var keepBlob = blob.slice();
var intent = new Intent(-x-my-intent, blob);
navigator.startActivity(intent, callback);


And we might have an error on postMessage stashing it in the
transfer array if it's not a Transferable on an older browser.





Example of how easy the neutered concept applies to Transferrable:

var blob = new Blob(my big blob);
blob.close();


I like the idea of having Blob implement Transferrable and adding close 
to the Transferrable interface.
File.close could have a better relationship with the cache and/or locks 
on data.



Some history on Transferrable and structured clones:

Note: MessagePort does have a close method and is currently the only 
Transferrable mentioned in WHATWG:

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable-objects

ArrayBuffer is widely implemented. It was the second item to implement 
Transferrable:

http://www.khronos.org/registry/typedarray/specs/latest/#9

Subsequently, ImageData adopted Uint8ClampedArray for one of its 
properties, adopting TypedArrays:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#imagedata

This has lead to some instability in the structured clone algorithm for 
ImageData as the typed array object for ImageData is read-only.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=13800

ArrayBuffer is still in a strawman state.

-Charles

Re: [fileapi] timing of readyState changes vs. events

[Anne van Kesteren]

On Fri, 02 Mar 2012 23:31:38 +0100, Eric U er...@google.com wrote:
On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren ann...@opera.com  
wrote:
Uhm. What you need to do is queue a task that changes the state and  
fires the event. You cannot just fire an event from asynchronous  
operations.


Pardon my ignorance, but why not?  Is it because you have to define
which task queue gets the operation?


Yeah, otherwise it would be undefined when the operation occurs relative  
to other asynchronous tasks, such as timeouts, events, and fetching.




So would that mean that e.g. the current spec for readAsDataURL would
have to queue steps 6 and 8-10?


Yeah. Actually, I think you want to queue a single task when the read is  
completed and then do 7, 8, 6, 9, 10 within that task (in that order, the  
current order seems wrong).



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [fileapi] timing of readyState changes vs. events

[Eric U]

On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren ann...@opera.com wrote:
 On Fri, 02 Mar 2012 01:01:55 +0100, Eric U er...@google.com wrote:

 On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
 aranganat...@mozilla.com wrote:

 OK, so the change is to ensure that these events are fired directly, and
 not queued, right?  I'll make this change.  This applies to all readAs*
 methods.


 Yup.  It should apply to any event associated with a state change [so
 e.g. onload, but not onloadend].


 Uhm. What you need to do is queue a task that changes the state and fires
 the event. You cannot just fire an event from asynchronous operations.

Pardon my ignorance, but why not?  Is it because you have to define
which task queue gets the operation?
So would that mean that e.g. the current spec for readAsDataURL would
have to queue steps 6 and 8-10?

Anyway, my point was just that load needed to be done synchronously
with the change to readyState, but loadend had no such restriction,
since it wasn't tied to the readyState change.

Re: [fileapi] timing of readyState changes vs. events

[Arun Ranganathan]

Eric,

 On Fri, 02 Mar 2012 01:01:55 +0100, Eric U er...@google.com wrote:
  On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
  aranganat...@mozilla.com wrote:
  OK, so the change is to ensure that these events are fired
  directly,
  and not queued, right?  I'll make this change.  This applies to
  all
  readAs* methods.
 
  Yup.  It should apply to any event associated with a state change
  [so
  e.g. onload, but not onloadend].
 
 Uhm. What you need to do is queue a task that changes the state and
 fires
 the event. You cannot just fire an event from asynchronous
 operations.


Anne's right (asynchronous operations happen on the event queue).

I think the same task can change state and fire the event.  This may take care 
of the timing issue.

-- A*

Re: [FileAPI] Deterministic release of Blob proposal

[Charles Pritchard]

On 3/2/2012 4:54 PM, Feras Moussa wrote:


At TPAC we discussed the ability to deterministically close blobs with 
a few


others.



...


To address this issue, we propose that a close method be added to the 
Blob


interface.

When called, the close method should release the underlying resource 
of the


Blob, and future operations on the Blob will return a new error, a 
ClosedError.


This allows an application to signal when it's finished using the Blob.




I suppose the theory of Blob is that it can be written to disk. The 
other theory is that reference counting can somehow work magic.

I'm not sure, but it came up before.

I brought up a close mechanism for ArrayBuffer, which is (I believe) 
supposed to be in memory, always.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029741.html

Also referenced:
http://www.khronos.org/webgl/public-mailing-list/archives/1009/msg00229.html

ArrayBuffer can now be closed out of the current thread via Transferable 
semantics.

I don't know if it disappears into space with an empty postMessage target.

I don't think that works for Blob, though.

Yes, I'd like to see immediate mechanisms to cleanup Blob and ArrayBuffer.
In practical use, it wasn't an issue on the desktop and the iPhone 
hadn't picked up the semantics yet.


But gosh it's no fun trying to navigate memory management on mobile 
device. Thus my low memory event thread.


-Charles

Re: [fileapi] timing of readyState changes vs. events

[Arun Ranganathan]

Eric,

 In the readAsText in the latest draft [1] I see that readyState gets
 set to done When the blob has been read into memory fully.
 I see that elsewhere in the progress notification description, When
 the data from the blob has been completely read into memory, queue a
 task to fire a progress event called load.  So readyState changes
 separately from the sending of that progress event, since one is
 direct and the other queued, and script could observe the state in
 between.
 
 In the discussion at [2] we arranged to avoid that for FileWriter.
  We
 should do the same for FileReader.

OK, so the change is to ensure that these events are fired directly, and not 
queued, right?  I'll make this change.  This applies to all readAs* methods.

-- A*

Re: [fileapi] timing of readyState changes vs. events

[Eric U]

On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
 Eric,

 In the readAsText in the latest draft [1] I see that readyState gets
 set to done When the blob has been read into memory fully.
 I see that elsewhere in the progress notification description, When
 the data from the blob has been completely read into memory, queue a
 task to fire a progress event called load.  So readyState changes
 separately from the sending of that progress event, since one is
 direct and the other queued, and script could observe the state in
 between.

 In the discussion at [2] we arranged to avoid that for FileWriter.
  We
 should do the same for FileReader.

 OK, so the change is to ensure that these events are fired directly, and not 
 queued, right?  I'll make this change.  This applies to all readAs* methods.

Yup.  It should apply to any event associated with a state change [so
e.g. onload, but not onloadend].

Re: [fileapi] timing of readyState changes vs. events

[Anne van Kesteren]

On Fri, 02 Mar 2012 01:01:55 +0100, Eric U er...@google.com wrote:

On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
OK, so the change is to ensure that these events are fired directly,  
and not queued, right?  I'll make this change.  This applies to all  
readAs* methods.


Yup.  It should apply to any event associated with a state change [so
e.g. onload, but not onloadend].


Uhm. What you need to do is queue a task that changes the state and fires  
the event. You cannot just fire an event from asynchronous operations.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Arun Ranganathan]

On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan  aranganat...@mozilla.com  
wrote: 

  or use another algorithm with an identical result, and be decoded
  as UTF-8.

 I think this can be removed. You can always replace algorithms with
 equivalent ones, in any part of an implementation.

  and be decoded as UTF-8.

 This should say encoded. Unicode codepoints are the raw data;
 UTF-8 is the encoding of that data.

Done. 

 Should the actual UTF-8 encoding algorithm be specified by HTML?

I don't know, since I think that Unicode to UTF-8 is pretty common. Might help 
if it was part of the common infrastructure. 

-- A* 

 I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16157 for
 WebSocket.

 --
 Glenn Maynard

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Glenn Adams]

On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan
aranganat...@mozilla.comwrote:

 On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan 
 aranganat...@mozilla.com wrote:

 Should the actual UTF-8 encoding algorithm be specified by HTML?

 I don't know, since I think that Unicode to UTF-8 is pretty common.  Might
 help if it was part of the common infrastructure.


what needs to be specified that isn't already found in Unicode [1], clause
D92, p92ff?

[1] http://www.unicode.org/versions/Unicode6.1.0/ch03.pdf

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Arun Ranganathan]

On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan  aranganat...@mozilla.com  
wrote: 

  On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan 
  aranganat...@mozilla.com  wrote:
 

   Should the actual UTF-8 encoding algorithm be specified by HTML?
  
 
  I don't know, since I think that Unicode to UTF-8 is pretty common.
  Might help if it was part of the common infrastructure.
 

 what needs to be specified that isn't already found in Unicode [1],
 clause D92, p92ff?

 [1] http://www.unicode.org/versions/Unicode6.1.0/ch03.pdf
I think that gets us by. Do you think we need a reference in FileAPI? Or can we 
merely say to encode as UTF-8 and leave it to implementations (a reasonable 
assumption IMHO). 

-- A* 

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Glenn Adams]

On Wed, Feb 29, 2012 at 2:58 PM, Arun Ranganathan
aranganat...@mozilla.comwrote:

 On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan 
 aranganat...@mozilla.com wrote:

  On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan 
 aranganat...@mozilla.com wrote:

 Should the actual UTF-8 encoding algorithm be specified by HTML?

 I don't know, since I think that Unicode to UTF-8 is pretty common.
 Might help if it was part of the common infrastructure.


 what needs to be specified that isn't already found in Unicode [1], clause
 D92, p92ff?

 [1] http://www.unicode.org/versions/Unicode6.1.0/ch03.pdf


 I think that gets us by.  Do you think we need a reference in FileAPI?  Or
 can we merely say to encode as UTF-8 and leave it to implementations (a
 reasonable assumption IMHO).


I think you should have a reference. You could either use the following, as
does HTML5:

[RFC3629]UTF-8, a transformation format of ISO
10646http://tools.ietf.org/html/rfc3629,
F. Yergeau. IETF.

or you could modify the language in Section 4 Terminology and Algorithms to
read:

The terms and algorithms *UTF-8*, fragment, scheme, document, unloading
document cleanup steps, event handler attributes, event handler event type,
origin, same origin, event loops, task, task source, URL, and queue a task are
defined by the HTML specification
[HTMLhttp://dev.w3.org/2006/webapi/FileAPI/#HTML
].


HTML

A conforming user
agenthttp://dev.w3.org/2006/webapi/FileAPI/#dfn-conforming-implementation
MUST
support at least the subset of the functionality defined in HTML that this
specification relies upon; in particular, it must support event
loopshttp://dev.w3.org/2006/webapi/FileAPI/#event-loops
 and event handler
attributeshttp://dev.w3.org/2006/webapi/FileAPI/#event-handler-attributes.
[HTML http://dev.w3.org/2006/webapi/FileAPI/#HTML]

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Glenn Adams]

On Wed, Feb 29, 2012 at 3:43 PM, Glenn Adams gl...@skynav.com wrote:


 HTML

 A conforming user 
 agenthttp://dev.w3.org/2006/webapi/FileAPI/#dfn-conforming-implementation 
 MUST
 support at least the subset of the functionality defined in HTML that this
 specification relies upon; in particular, it must support event 
 loopshttp://dev.w3.org/2006/webapi/FileAPI/#event-loops
  and event handler 
 attributeshttp://dev.w3.org/2006/webapi/FileAPI/#event-handler-attributes.
 [HTML http://dev.w3.org/2006/webapi/FileAPI/#HTML]

Ignore the above paragraph.

RE: [FileAPI] createObjectURL isReusable proposal

[Feras Moussa]

We think the new property bag (objectURLOptions) semantics in the latest 
editors draft are very reasonable. We have an implementation of this and 
from our experience have found it very widely used internally with app 
developers - many leverage it as a way to get an easy to use one-time-use 
URL and avoid leaks in their applications. We've also noticed many 
developers easily overlook the URL.revokeObjectURL API, thus failing to 
realize they are pinning the resource behind the blob and further validating 
the usefulness of this.
 
To address a few of the implementation questions that were raised in 
this thread:
 Something else that needs to be defined: does xhr.open('GET', url) 
 consume the URL, or does that only happen when xhr.send() is called?
We think a URL does not get consumed until the data has been accessed. As 
XHR does not begin accessing the data until send has been called, we expect 
Blob URLs to be no different. The URL should get revoked  after xhr.send() 
gets called. This is also what we've done in our implementation, and have not 
noticed any confusion from developers.
 
Another case: whether loading a one-shot URL from a different origin, 
where you aren't allowed to load the content, still causes the URL to 
be revoked.  (My first impression was that it shouldn't affect it at 
all, but my second impression is that in practice that error mode would 
probably always result in the URL never being revoked and ending up 
leaked, so it's probably best to free it anyway.)
Similar to the above case, the URL is not revoked until after the data is 
accessed. If a URL is used from a different site of origin, the download fails 
and the data is not accessed, thus the URL is not revoked. Developers can 
notice this condition from the onerror handler for an img tag, where they 
can revoke the URL if it did not resolve correctly.
 
 What do you think of a global release mechanism? Such as 
 URL.revokeAllObjectUrls();
This wouldn't solve any of the problems previously listed in this thread, 
and would only be useful as a convenience API. That said, I'd question 
the trade-off of adding another API versus a developer writing their 
own version of this, which should be fairly trivial.
 
We also think the spec should clarify what the expected behavior is for 
a revoked URL when accounting for the image cache. The concept of 
revoking URLs is to give the developer a way to say they are done with 
the object. If a user agent still has the bits in memory, it should not be 
in the business of blocking the URL from loading, even if it is revoked.
 
We’d like to see the spec updated to clarify the points listed above 
and I'd be happy to help with these changes in any way possible.
 
Thanks,
Feras

 -Original Message-
 From: Bronislav Klučka [mailto:bronislav.klu...@bauglir.com]
 Sent: Friday, February 24, 2012 1:10 PM
 To: public-webapps@w3.org
 Cc: public-webapps@w3.org
 Subject: Re: [FileAPI] createObjectURL isReusable proposal
 
 
 
 On 24.2.2012 20:49, Arun Ranganathan wrote:
  On 24.2.2012 20:12, Arun Ranganathan wrote:
  Bronislav,
 
 
  I could also go with reverse approach, with createObjectURL being
  oneTimeOnly by default createObjectURL(Blob aBlob, boolean?
  isPermanent) instead of current createObjectURL(Blob aBlob,
  boolean? isOneTime) the fact, that user would have to explicitly
  specify, that such URL is permanent should limit cases of I forgot
  to release something somewhere... and I thing could be easier to
  understant, that explicit request for pemranent = explicit release.
  Would break current implementations, sure, but if we are
  considering changes
  So, having these URLs be oneTimeOnly by default itself has issues,
  as Glenn (and Darin) point out:
 
  http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0377.h
  tml
 
  The existing model makes that scenario false by default, trading off
  anything racy against culling strings.
  We are back in an issue of someone using oneTimeOnly or permanent in
  an inappropriate case.  Programmers should be aware of what they are
  doing.
  I actually have no problem with current specification (rermanent as
  default, expicit release), I'm just trying to prevent changes like
  assigning object to string attribute (e.g. src), returning innerHTML
  with empty string attribute (e.g. src)
 
  My solution is that src should be modified to take both a string and a URL
 object, which makes innerHTML behavior easier; I'm less sure of it taking Blob
 directly.
 
  -- A*
 What change would it make compared to current scenario? URL as string or URL
 as stringifiable object? What's the difference?
 
 
 B.
 
 

Re: [FileAPI] createObjectURL isReusable proposal

[Glenn Maynard]

On Wed, Feb 29, 2012 at 9:38 PM, Feras Moussa fer...@microsoft.com wrote:

  Another case: whether loading a one-shot URL from a different origin,
 where you aren't allowed to load the content, still causes the URL to
 be revoked.  (My first impression was that it shouldn't affect it at
 all, but my second impression is that in practice that error mode would
 probably always result in the URL never being revoked and ending up
 leaked, so it's probably best to free it anyway.)
 Similar to the above case, the URL is not revoked until after the data is
 accessed. If a URL is used from a different site of origin, the download
 fails
 and the data is not accessed, thus the URL is not revoked. Developers can
 notice this condition from the onerror handler for an img tag, where they
 can revoke the URL if it did not resolve correctly.


I think they'd be very unlikely to notice, because the only side-effect is
a reference leak wasting memory.  The entire point of this API is to handle
that collection for you; it should do it as consistently as can be
managed.  If you have to carefully watch onerror and release the URL in
some cases, then the problem hasn't been solved at all.

It makes more sense for the URL to be revoked upon entry to an API that
uses the URL.  The API, when it receives a URL, implicitly dereferences it
to the underlying resource (retaining that reference), and revokes the
URL.  This always happens, even if the fetch fails for any reason (such as
cross-origin restrictions), or even if the fetch never happens.

An example of another problem this solves: if a UA obtains images on
demand [1], it may never update the image data if the image is not
actually in a document (and possibly not even if it is).  If the URL is
only released on access (fetch), then it would never be released.  By
releasing the URL immediately (in this case, on assignment to
HTMLImageElement.src) and keeping an internal reference to the underlying
resource (the blob), this problem doesn't happen, and the release of the
URL happens at a consistent time, improving interoperability.

[1] http://dev.w3.org/html5/spec/Overview.html#the-img-element



   What do you think of a global release mechanism? Such as
  URL.revokeAllObjectUrls();
 This wouldn't solve any of the problems previously listed in this thread,
 and would only be useful as a convenience API. That said, I'd question
 the trade-off of adding another API versus a developer writing their
 own version of this, which should be fairly trivial.


I think a revokeAll API would be very bad.  It would allow completely
unrelated pieces of code running on a site to interfere with one another;
using an API like this would almost always be the wrong thing to do.

We also think the spec should clarify what the expected behavior is for
 a revoked URL when accounting for the image cache. The concept of
 revoking URLs is to give the developer a way to say they are done with
 the object. If a user agent still has the bits in memory, it should not be
 in the business of blocking the URL from loading, even if it is revoked.


If the HTMLImageElement has already performed the fetch and has the
resulting data cached, and needs to access it again later (eg. because the
decompressed data was discarded while it was off-screen), then yes.
However, if you revoke a URL, then assign the URL to an image, that fetch
should always fail, even if the blob happens to have not yet been GC'd.  In
that case, the bits are in memory, but the URL should always fail to load.

-- 
Glenn Maynard

Re: [FileAPI] createObjectURL isReusable proposal

[Bronislav Klučka]

On 1.3.2012 4:38, Feras Moussa wrote:

We think the new property bag (objectURLOptions) semantics in the latest
editors draft are very reasonable. We have an implementation of this and
from our experience have found it very widely used internally with app
developers - many leverage it as a way to get an easy to use one-time-use
URL and avoid leaks in their applications. We've also noticed many
developers easily overlook the URL.revokeObjectURL API, thus failing to
realize they are pinning the resource behind the blob and further validating
the usefulness of this.

To address a few of the implementation questions that were raised in
this thread:

Something else that needs to be defined: does xhr.open('GET', url)
consume the URL, or does that only happen when xhr.send() is called?

We think a URL does not get consumed until the data has been accessed. As
XHR does not begin accessing the data until send has been called, we expect
Blob URLs to be no different. The URL should get revoked  after xhr.send()
gets called. This is also what we've done in our implementation, and have not
noticed any confusion from developers.


Another case: whether loading a one-shot URL from a different origin,
where you aren't allowed to load the content, still causes the URL to
be revoked.  (My first impression was that it shouldn't affect it at
all, but my second impression is that in practice that error mode would
probably always result in the URL never being revoked and ending up
leaked, so it's probably best to free it anyway.)

Similar to the above case, the URL is not revoked until after the data is
accessed. If a URL is used from a different site of origin, the download fails
and the data is not accessed, thus the URL is not revoked. Developers can
notice this condition from the onerror handler for an img tag, where they
can revoke the URL if it did not resolve correctly.


What do you think of a global release mechanism? Such as
URL.revokeAllObjectUrls();

This wouldn't solve any of the problems previously listed in this thread,
and would only be useful as a convenience API. That said, I'd question
the trade-off of adding another API versus a developer writing their
own version of this, which should be fairly trivial.

We also think the spec should clarify what the expected behavior is for
a revoked URL when accounting for the image cache. The concept of
revoking URLs is to give the developer a way to say they are done with
the object. If a user agent still has the bits in memory, it should not be
in the business of blocking the URL from loading, even if it is revoked.

We’d like to see the spec updated to clarify the points listed above
and I'd be happy to help with these changes in any way possible.

Thanks,
Feras



Hi,
are we talking about
http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
?
because I still do not see, what have you solved...
Ok, instead of mutable string, you have an object, fine
but when you create this URL object out of Blob and assign that URL to 
HTMLImageElement source, you are stuck again

1/ when will be such URL object be GC'd?
2/ when will underlying Blob be GC'd?
3/ what would @src of that image return? (or ancestor's innerHTML)?



Brona

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Jonas Sicking]

On Tue, Feb 28, 2012 at 7:11 AM, Simon Pieters sim...@opera.com wrote:
 On Tue, 28 Feb 2012 01:05:44 +0100, Glenn Maynard gl...@zewt.org wrote:

 On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan
 aranganat...@mozilla.comwrote:

 Simon,

 Is the relevant part of HTML sufficient to refer to?
 http://dev.w3.org/html5/spec/Overview.html#utf-8


 I was thinking of If the data argument has any unpaired surrogates, then
 throw a SyntaxError exception..
 http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#dom-websocket-send



 That defines decoding UTF-8 to Unicode strings.  You need the reverse.

 Using a replacement scheme like UTF-8 decoding, instead of a hard
 exception, seems more consistent with how encodings in general are
 handled.  Otherwise, you'll end up with bugs in code if, for example,
 people paste in unpaired surrogates (Firefox allows this, last I checked),


 Maybe unpaired surrogates should be converted to U+FFFD on paste. Are there
 other cases?


 causing unexpected exceptions in code.  Instead, just convert them to
 U+FFFD, which gives much more graceful error handling for such a rare case
 that most people will never handle explicitly.


 If we can't U+FFFD unpaired surrogates on paste, I agree it makes sense to
 U+FFFD them in APIs. If the only way to get them is a JS escape, then an
 exception seems OK.

People use JS strings to handle binary data. This is something that
has worked since the dawn of JS and is something that I believe is
defined to work in recent ECMAScript specs.

I don't think that we can start restricting that and try to enforce
that JS-strings always contain valid UTF16.

So I think our only option is to make all APIs which does UTF16-UTF8
conversion explicitly define how to deal with invalid surrogates. My
preference would be to deal with them by encoding them to U+FFFD for
the same reason that we let the HTML parser do error recovery rather
than XML-style draconian error handling.

/ Jonas

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Simon Pieters]

On Tue, 28 Feb 2012 13:05:37 +0100, Jonas Sicking jo...@sicking.cc wrote:

If we can't U+FFFD unpaired surrogates on paste, I agree it makes sense  
to

U+FFFD them in APIs. If the only way to get them is a JS escape, then an
exception seems OK.


People use JS strings to handle binary data. This is something that
has worked since the dawn of JS and is something that I believe is
defined to work in recent ECMAScript specs.

I don't think that we can start restricting that and try to enforce
that JS-strings always contain valid UTF16.


Right.


So I think our only option is to make all APIs which does UTF16-UTF8
conversion explicitly define how to deal with invalid surrogates.


Sure, I don't suggest we leave it undefined.


My
preference would be to deal with them by encoding them to U+FFFD for
the same reason that we let the HTML parser do error recovery rather
than XML-style draconian error handling.


I'm not really opposed to making APIs use U+FFFD instead of exception, but  
I'm not entirely convinced, either. If people use binary data in strings  
and want to use them in these APIs, U+FFFDing lone surrogates is going to  
silently scramble their data. Why is this better than throwing an  
exception?


--
Simon Pieters
Opera Software

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Jonas Sicking]

On Tue, Feb 28, 2012 at 1:57 PM, Simon Pieters sim...@opera.com wrote:
 My
 preference would be to deal with them by encoding them to U+FFFD for
 the same reason that we let the HTML parser do error recovery rather
 than XML-style draconian error handling.

 I'm not really opposed to making APIs use U+FFFD instead of exception, but
 I'm not entirely convinced, either. If people use binary data in strings and
 want to use them in these APIs, U+FFFDing lone surrogates is going to
 silently scramble their data. Why is this better than throwing an
 exception?

I'm not so much worried that people will store binary and then attempt
to send it as text. I'm more worried people will do things like cut up
a string into parts and send the parts separately, or have bugs in
some search'n'replace code which could result in invalid surrogates
being created and then send the resulting strings over a websocket.
The error conditions would be very intermittent since it would
entirely depend on the data (which could be user provided) which is
being processed and so might not reproduce easily for the developer.

I agree that it scrambles the data. But no more than the HTML parser
error recovery does. And if an unexpected exception is thrown then the
result is likely dataloss which is not obviously better than
scrambling part of the data.

/ Jonas

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Glenn Maynard]

On Tue, Feb 28, 2012 at 12:11 AM, Simon Pieters sim...@opera.com wrote:

 I think WebSocket should do the same, for the same reason.

 Have you filed a bug?


(No, not until this conversation moves along a bit further.)


On Tue, Feb 28, 2012 at 8:26 AM, Jonas Sicking jo...@sicking.cc wrote:

 I agree that it scrambles the data. But no more than the HTML parser
 error recovery does. And if an unexpected exception is thrown then the
 result is likely dataloss which is not obviously better than
 scrambling part of the data.


I'd say it's weaker than scrambles, actually, at least with
human-readable text.  Replacing one character with U+FFFD usually results
in an isolated glitch that a reader can recover from.  (I do this regularly
when reading the HTML spec, which uses characters not widely supported, in
particular Steps in synchronous sections are marked with ?.)

Also, even if you're attentive to handling these errors, most of the time
you don't want to.  In my experience, it's very uncommon to want to
explicitly handle very rare errors like the user pasted in an unpaired
surrogate.  There's rarely anything useful you can do, except to walk
through the string and change the unpaired surrogates to U+FFFD, so you can
move on.  I'd rather just get U+FFFD to begin with.

-- 
Glenn Maynard

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Arun Ranganathan]

On Tue, Feb 28, 2012 at 12:11 AM, Simon Pieters  sim...@opera.com  wrote: 

  I think WebSocket should do the same, for the same reason.
 

  Have you filed a bug?
 
 (No, not until this conversation moves along a bit further.)

 On Tue, Feb 28, 2012 at 8:26 AM, Jonas Sicking jo...@sicking.cc
 wrote:

  I agree that it scrambles the data. But no more than the HTML
  parser error recovery does. And if an unexpected exception is
  thrown
  then the
 
  result is likely dataloss which is not obviously better than
 
  scrambling part of the data.
 

 I'd say it's weaker than scrambles, actually, at least with
 human-readable text. Replacing one character with U+FFFD usually
 results in an isolated glitch that a reader can recover from. (I do
 this regularly when reading the HTML spec, which uses characters not
 widely supported, in particular Steps in synchronous sections are
 marked with ?.)

 Also, even if you're attentive to handling these errors, most of the
 time you don't want to. In my experience, it's very uncommon to want
 to explicitly handle very rare errors like the user pasted in an
 unpaired surrogate. There's rarely anything useful you can do,
 except to walk through the string and change the unpaired surrogates
 to U+FFFD, so you can move on. I'd rather just get U+FFFD to begin
 with.
OK, I've updated the Editor's Draft to reflect this. Essentially, I take Anne's 
advice about first converting the DOMString to a sequence of Unicode characters 
using the algorithm defined in WebIDL (namely this one: 
http://dev.w3.org/2006/webapi/WebIDL/#dfn-obtain-unicode). 

This actually seems to take care of unmatched surrogates from UTF-16 when you 
use a UTF-8 decoding on the Unicode characters following the algorithmic 
conversion, and so we may have what we need here. 

This is the 29th February Editor's Draft (ensure you shift-reload if 
necessary): 

http://dev.w3.org/2006/webapi/FileAPI/ 

I'd appreciate a review. If this passes muster, we may be one step further 
along the way to deprecating BlobBuilder, which only stipulated writing out as 
UTF-8 when the DOMString was appended to the Blob. 

-- A* 

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Glenn Maynard]

On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan
aranganat...@mozilla.comwrote:
 or use another algorithm with an identical result, and be decoded as
UTF-8.

I think this can be removed.  You can always replace algorithms with
equivalent ones, in any part of an implementation.

 and be decoded as UTF-8.

This should say encoded.  Unicode codepoints are the raw data; UTF-8 is
the encoding of that data.

Should the actual UTF-8 encoding algorithm be specified by HTML?

I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16157 for
WebSocket.

-- 
Glenn Maynard

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Eric U]

What I can do is procrastinate until we agree that BlobBuilder is
deprecated, and this is now the problem of the Blob constructor.  Over
to you, Arun and Jonas.

On Mon, Sep 26, 2011 at 11:45 AM, Eric U er...@google.com wrote:
 Thanks Glenn and Simon--I'll see what I can do.


 On Fri, Sep 23, 2011 at 1:34 AM, Simon Pieters sim...@opera.com wrote:

 On Fri, 23 Sep 2011 01:40:44 +0200, Glenn Maynard gl...@zewt.org wrote:

 BlobBuilder.append(text) says:

 Appends the supplied text to the current contents of the BlobBuilder,

 writing it as UTF-8, converting newlines as specified in endings.

 It doesn't elaborate any further.  The conversion from UTF-16 to UTF-8
 needs
 to be defined, in particular for the edge case of invalid UTF-16
 surrogates.  If this is already defined somewhere, it isn't referenced.

 I suppose this would belong in Common infrastructure, next to the
 existing
 section on UTF-8, not in FileAPI itself.


 WebSocket send() throws SYNTAX_ERR if its argument contains unpaired
 surrogates. It would be nice to be consistent.

 --
 Simon Pieters
 Opera Software

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Arun Ranganathan]

Simon,

Is the relevant part of HTML sufficient to refer to?  
http://dev.w3.org/html5/spec/Overview.html#utf-8



 What I can do is procrastinate until we agree that BlobBuilder is
 deprecated, and this is now the problem of the Blob constructor.
  Over
 to you, Arun and Jonas.
 
 On Mon, Sep 26, 2011 at 11:45 AM, Eric U er...@google.com wrote:
  Thanks Glenn and Simon--I'll see what I can do.
 
 
  On Fri, Sep 23, 2011 at 1:34 AM, Simon Pieters sim...@opera.com
  wrote:
 
  On Fri, 23 Sep 2011 01:40:44 +0200, Glenn Maynard gl...@zewt.org
  wrote:
 
  BlobBuilder.append(text) says:
 
  Appends the supplied text to the current contents of the
  BlobBuilder,
 
  writing it as UTF-8, converting newlines as specified in endings.
 
  It doesn't elaborate any further.  The conversion from UTF-16 to
  UTF-8
  needs
  to be defined, in particular for the edge case of invalid UTF-16
  surrogates.  If this is already defined somewhere, it isn't
  referenced.
 
  I suppose this would belong in Common infrastructure, next to
  the
  existing
  section on UTF-8, not in FileAPI itself.
 
 
  WebSocket send() throws SYNTAX_ERR if its argument contains
  unpaired
  surrogates. It would be nice to be consistent.
 
  --
  Simon Pieters
  Opera Software
 
 
 

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Glenn Maynard]

On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan
aranganat...@mozilla.comwrote:

 Simon,

 Is the relevant part of HTML sufficient to refer to?
 http://dev.w3.org/html5/spec/Overview.html#utf-8


That defines decoding UTF-8 to Unicode strings.  You need the reverse.

Using a replacement scheme like UTF-8 decoding, instead of a hard
exception, seems more consistent with how encodings in general are
handled.  Otherwise, you'll end up with bugs in code if, for example,
people paste in unpaired surrogates (Firefox allows this, last I checked),
causing unexpected exceptions in code.  Instead, just convert them to
U+FFFD, which gives much more graceful error handling for such a rare case
that most people will never handle explicitly.

I think WebSocket should do the same, for the same reason.

-- 
Glenn Maynard

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Anne van Kesteren]

On Tue, 28 Feb 2012 00:34:57 +0100, Arun Ranganathan  
aranganat...@mozilla.com wrote:
Is the relevant part of HTML sufficient to refer to?   
http://dev.w3.org/html5/spec/Overview.html#utf-8


That is UTF-8 octets - Unicode code points. UTF-16 - UTF-8 is different.  
You want the algorithm in Web IDL that takes a DOMString and gives you  
Unicode. And then from Unicode you go to UTF-8. If you want it to never  
fail that is and not generate broken UTF-8.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

[Simon Pieters]

On Tue, 28 Feb 2012 01:05:44 +0100, Glenn Maynard gl...@zewt.org wrote:


On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan
aranganat...@mozilla.comwrote:


Simon,

Is the relevant part of HTML sufficient to refer to?
http://dev.w3.org/html5/spec/Overview.html#utf-8


I was thinking of If the data argument has any unpaired surrogates, then  
throw a SyntaxError exception..  
http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#dom-websocket-send




That defines decoding UTF-8 to Unicode strings.  You need the reverse.

Using a replacement scheme like UTF-8 decoding, instead of a hard
exception, seems more consistent with how encodings in general are
handled.  Otherwise, you'll end up with bugs in code if, for example,
people paste in unpaired surrogates (Firefox allows this, last I  
checked),


Maybe unpaired surrogates should be converted to U+FFFD on paste. Are  
there other cases?



causing unexpected exceptions in code.  Instead, just convert them to
U+FFFD, which gives much more graceful error handling for such a rare  
case

that most people will never handle explicitly.


If we can't U+FFFD unpaired surrogates on paste, I agree it makes sense to  
U+FFFD them in APIs. If the only way to get them is a JS escape, then an  
exception seems OK.



I think WebSocket should do the same, for the same reason.


Have you filed a bug?

--
Simon Pieters
Opera Software

Re: [FileAPI] createObjectURL isReusable proposal

[Arun Ranganathan]

Bronislav,

 
 I could also go with reverse approach, with createObjectURL being
 oneTimeOnly by default
 createObjectURL(Blob aBlob, boolean? isPermanent)
 instead of current
 createObjectURL(Blob aBlob, boolean? isOneTime)
 the fact, that user would have to explicitly specify, that such URL
 is
 permanent should limit cases of I forgot to release something
 somewhere... and I thing could be easier to understant, that
 explicit
 request for pemranent = explicit release. Would break current
 implementations, sure, but if we are considering changes


So, having these URLs be oneTimeOnly by default itself has issues, as Glenn 
(and Darin) point out:

http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0377.html

The existing model makes that scenario false by default, trading off anything 
racy against culling strings.

I actually believe that strings for URLs may be short-lived, depending on how 
the URL API comes along [1] and depending on the discussion on extending 
interfaces.  Both Chrome and Fx have create* and revoke* implemented now; the 
new options parameter adds some convenience which I think is worth it.

-- A*

[1] http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html


 
 B.
 
 
 
 

Re: [FileAPI] createObjectURL isReusable proposal

[Bronislav Klučka]

On 24.2.2012 20:12, Arun Ranganathan wrote:

Bronislav,



I could also go with reverse approach, with createObjectURL being
oneTimeOnly by default
createObjectURL(Blob aBlob, boolean? isPermanent)
instead of current
createObjectURL(Blob aBlob, boolean? isOneTime)
the fact, that user would have to explicitly specify, that such URL
is
permanent should limit cases of I forgot to release something
somewhere... and I thing could be easier to understant, that
explicit
request for pemranent = explicit release. Would break current
implementations, sure, but if we are considering changes


So, having these URLs be oneTimeOnly by default itself has issues, as Glenn 
(and Darin) point out:

http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0377.html

The existing model makes that scenario false by default, trading off anything 
racy against culling strings.
We are back in an issue of someone using oneTimeOnly or permanent in an 
inappropriate case.  Programmers should be aware of what they are doing.
I actually have no problem with current specification (rermanent as 
default, expicit release), I'm just trying to prevent changes like 
assigning object to string attribute (e.g. src), returning innerHTML 
with empty string attribute (e.g. src)

Brona.

Re: [FileAPI] createObjectURL isReusable proposal

[Arun Ranganathan]

 On 24.2.2012 20:12, Arun Ranganathan wrote:
  Bronislav,
 
 
  I could also go with reverse approach, with createObjectURL being
  oneTimeOnly by default
  createObjectURL(Blob aBlob, boolean? isPermanent)
  instead of current
  createObjectURL(Blob aBlob, boolean? isOneTime)
  the fact, that user would have to explicitly specify, that such
  URL
  is
  permanent should limit cases of I forgot to release something
  somewhere... and I thing could be easier to understant, that
  explicit
  request for pemranent = explicit release. Would break current
  implementations, sure, but if we are considering changes
 
  So, having these URLs be oneTimeOnly by default itself has
  issues, as Glenn (and Darin) point out:
 
  http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0377.html
 
  The existing model makes that scenario false by default, trading
  off anything racy against culling strings.
 We are back in an issue of someone using oneTimeOnly or permanent in
 an
 inappropriate case.  Programmers should be aware of what they are
 doing.
 I actually have no problem with current specification (rermanent as
 default, expicit release), I'm just trying to prevent changes like
 assigning object to string attribute (e.g. src), returning innerHTML
 with empty string attribute (e.g. src)


My solution is that src should be modified to take both a string and a URL 
object, which makes innerHTML behavior easier; I'm less sure of it taking Blob 
directly.

-- A*

Re: [FileAPI] Various comments

[Arun Ranganathan]

Ms2ger,

Many thanks for the detailed review.


 
 == 1. Introduction ==
 
  Binary Large Object -- a name originally introduced to web APIs
  in Google Gears
 
 should use an en dash (—, U+2013) instead of two hyphens.


Done.


 
 This paragraph is inconsistent about linking File and Blob to their
 definitions.


Done.

 The example has
 
if(evt.target.error.name == NOT_READABLE_ERR) {
 
 which probably should be NotReadableError.


Done.

 
 == 2. Conformance ==
 
 I think it's surprising that notes are normative, unlike (AFAICT)
 most
 other Web API specifications.


Upon reflection, I have used notes rather liberally.  I've removed all 
normative notes making them just a part of the specification.

 == 4. Terminology and Algorithms ==
 
 The = and = operators don't seem to be used in the specification.


Eliminated reference to them.

 
 == 6. The Blob Interface ==
 
 The constructor can use the new WebIDL unions types, as
 
   Constructor((ArrayBuffer or Blob or DOMString)[] blobParts,
   optional BlobPropertyBag options)
 


Done.  Presumably WebIDL also handles what happens when a contructor is invoked 
with an argument not in the union type, so I don't need to say what happens in 
that case.

 === 6.1. Constructors ===
 
 The reference to ES5 doesn't seem necessary.
 


Done.

 === 6.2. Attributes ===
 
  On getting, conforming user agents SHOULD return the MIME type of
  the Blob, if it is known.
 
 Should be MUST, as we already have if it is known.


Done.

 
 === 6.3. Methods and Parameters ===
 
 The contentType normalization should not special-case undefined; if
 an
 author passes undefined, it should be treated as undefined per
 WebIDL.

Done.

 
 == 7. The File Interface ==
 
 Something's weird with the indentation in the IDL block here.


Fixed.

 
  readonly attribute Date lastModifiedDate;
 
 should be Date?, as it can return null.


Done.

 
 == 8. The FileReader Interface ==
 === 8.1. The FileReader Task Source ===
 
  The FileReader interface enables asynchronous reads on individual
  Blob objects by firing progress events as the read occurs to event
  handler methods on the FileReader, which is an EventTarget
  [DOMCore].
 
 This seems to suggest that one can only use the event handler methods
 (attributes?), but not add/removeEventListener. Maybe just remove to
 event handler methods.


Done.

 
 === 8.5. Reading a File or Blob ===
 
 The result attribute should probably be declared as
 
 | readonly attribute (DOMString or ArrayBuffer)? result;


Done.

 
  8.5.7. Blob Parameters 
 
 I have no idea what this section is actually supposed to define.


Clarified.

 
 = 8.5.9.1. Event Summary =
 
   … the table below is normative for the events in this
   specification.
 
 The table should not be normative; the events are already fired in
 the
 respective algorithms.


Done.

 
 = 8.5.9.2. Summary of Event Invariants =
 
   The following are normative invariants …
 
 What are normative invariants? This seems to be a list of
 statements
 of fact [1], and as such should be informative.

Done.

 
 == 10. Errors and Exceptions ==
 === 10.1. Throwing an Exception or Returning an Error ===
 
  Synchronous read methods throw exceptions of the type in the table
  below if there has been an error with reading or .


Fixed. 

 
 
 The EncodingError cell seems to confusingly use encoding for a
 concept
 related to the length of a data URL and character encodings; I don't
 see
 how these concepts are related.


The problem is in Base64-encoding long files subject to URL-length 
limitations.  I've clarified this.

 
 == 11. A URI for Blob and File reference ==
 === 11.1. Requirements for a New Scheme ===
 
 This section uses |img| and img inconsistently, it should use the
 former.

Done.

 
 === 11.2. Discussion of Existing Schemes ===
 
  Choosing a name that 
 
 En dashes again.

Done :)

 
 === 11.3. Definition of blob URI Scheme ===
 
  Opaque strings MUST NOT include any reserved characters from
  [RFC3986] without percent-encoding them; these characters MUST be
  percent-encoded.
 
 Redundant requirements.


Clarified.

 
 === 11.6. Lifetime of Blob URIs ===
 
 Should reference the oneTimeOnly argument here.


Done (great suggestion).

 
 === 11.8. Creating and Revoking a Blob URI ===
 
 // Window implements URL;
 // WorkerUtils implements URL;


Eliminated.

 
 === 11.9. Examples of Blob URI Creation and Revocation ===
 
  Blob URIs are strings that dereference Blob objects, and can
  persist
  for as long as the document from which they were minted using
  URL.createObjectURL() -- see _Lifetime of Blob URIs_.
 
 En dash, and the Lifetime of Blob URIs link is broken.


Fixed.

 
   In the example below, two Image elements
 
 Should say |img| elements for consistency.


Fixed.

 
 == 16. References ==
 
 Aryeh Gregor is now also editing DOM Core, which has been renamed to
 DOM4.
 
 The URL specification is now at
 

Re: [FileAPI] createObjectURL isReusable proposal

[Bronislav Klučka]

On 14.2.2012 5:56, Jonas Sicking wrote:

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch  wrote:

On Thu, 2 Feb 2012, Arun Ranganathan wrote:

2. Could we modify things so that img.src = blob is a reality? Mainly,
if we modify things for the *most common* use case, that could be useful
in mitigating some of our fears. Hixie, is this possible?

Anything's possible, but I think the pain here would far outweigh the
benefits. There would be some really hard questions to answer, too (e.g.
what would innerHTML return? If you copied such an image from a
contentEditable section and pasted it lower down the same section, would
it still have the image?).

We could define that it returns an empty src attribute, which would
break the copy/paste example. That's the same behavior you'd get with
someone revoking the URL upon load anyway.

/ Jonas



The point of reusable Blob URL is the compatibility with regular URL, 
not having reusable URL would create unpleasant dichotomy in data 
manipulating...


Brona

Re: [FileAPI] createObjectURL isReusable proposal

[Charles Pritchard]

On 2/14/2012 5:35 AM, Bronislav Klučka wrote:



On 14.2.2012 5:56, Jonas Sicking wrote:

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch  wrote:

On Thu, 2 Feb 2012, Arun Ranganathan wrote:

2. Could we modify things so that img.src = blob is a reality? Mainly,
if we modify things for the *most common* use case, that could be 
useful

in mitigating some of our fears. Hixie, is this possible?

Anything's possible, but I think the pain here would far outweigh the
benefits. There would be some really hard questions to answer, too 
(e.g.

what would innerHTML return? If you copied such an image from a
contentEditable section and pasted it lower down the same section, 
would

it still have the image?).

We could define that it returns an empty src attribute, which would
break the copy/paste example. That's the same behavior you'd get with
someone revoking the URL upon load anyway.

/ Jonas



The point of reusable Blob URL is the compatibility with regular URL, 
not having reusable URL would create unpleasant dichotomy in data 
manipulating...


What do you think of a global release mechanism? Such as 
URL.revokeAllObjectUrls();

Re: [FileAPI] createObjectURL isReusable proposal

[Bronislav Klučka]

On 14.2.2012 14:39, Charles Pritchard wrote:

On 2/14/2012 5:35 AM, Bronislav Klučka wrote:



On 14.2.2012 5:56, Jonas Sicking wrote:

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch  wrote:

On Thu, 2 Feb 2012, Arun Ranganathan wrote:
2. Could we modify things so that img.src = blob is a reality? 
Mainly,
if we modify things for the *most common* use case, that could be 
useful

in mitigating some of our fears. Hixie, is this possible?

Anything's possible, but I think the pain here would far outweigh the
benefits. There would be some really hard questions to answer, too 
(e.g.

what would innerHTML return? If you copied such an image from a
contentEditable section and pasted it lower down the same section, 
would

it still have the image?).

We could define that it returns an empty src attribute, which would
break the copy/paste example. That's the same behavior you'd get with
someone revoking the URL upon load anyway.

/ Jonas



The point of reusable Blob URL is the compatibility with regular URL, 
not having reusable URL would create unpleasant dichotomy in data 
manipulating...


What do you think of a global release mechanism? Such as 
URL.revokeAllObjectUrls();


Sounds like very interesting idea... could clearly solve a lot of issues 
here (load everything you want on load and the release it once) . So +1


But I would still leave some functionality for one image manipulation, 
there still can be apps with mixed approach (some images with reusable 
{application data}, some images without {application UI}), ore they may 
not be even images here (images one time, but some file blob permanent).
I could also go with reverse approach, with createObjectURL being 
oneTimeOnly by default

createObjectURL(Blob aBlob, boolean? isPermanent)
instead of current
createObjectURL(Blob aBlob, boolean? isOneTime)
the fact, that user would have to explicitly specify, that such URL is 
permanent should limit cases of I forgot to release something 
somewhere... and I thing could be easier to understant, that explicit 
request for pemranent = explicit release. Would break current 
implementations, sure, but if we are considering changes


B.

Re: [FileAPI] createObjectURL isReusable proposal

[Glenn Maynard]

2012/2/14 Bronislav Klučka bronislav.klu...@bauglir.com

 The point of reusable Blob URL is the compatibility with regular URL, not
 having reusable URL would create unpleasant dichotomy in data
 manipulating...


The point is avoiding the error-prone need to release resources by hand.

-- 
Glenn Maynard

Re: [FileAPI] createObjectURL isReusable proposal

[Bronislav Klučka]

On 14.2.2012 15:20, Glenn Maynard wrote:
2012/2/14 Bronislav Klučka bronislav.klu...@bauglir.com 
mailto:bronislav.klu...@bauglir.com


The point of reusable Blob URL is the compatibility with regular
URL, not having reusable URL would create unpleasant dichotomy in
data manipulating...


The point is avoiding the error-prone need to release resources by hand.

--
Glenn Maynard



Yes, that is why we have this thread, I was talking about Blob URL...
I'm trying to find solution that would solve both (sure, I do not mind 
explicit release).
I do not want solution where working with set of images would require to 
traverse through all images and somehow trying to determine whether 
images is regular URL or blob and go through 2 different branches.
Suggestions like We could define that it returns an empty src 
attribute prohibits any additional working with such image... accessing 
such image tells me nothing... is such image Blob image? Is it new empty 
image?


Brona

Re: [FileAPI] createObjectURL isReusable proposal

[Bronislav Klučka]

On 14.2.2012 5:56, Jonas Sicking wrote:

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch  wrote:

On Thu, 2 Feb 2012, Arun Ranganathan wrote:

2. Could we modify things so that img.src = blob is a reality? Mainly,
if we modify things for the *most common* use case, that could be useful
in mitigating some of our fears. Hixie, is this possible?

Anything's possible, but I think the pain here would far outweigh the
benefits. There would be some really hard questions to answer, too (e.g.
what would innerHTML return? If you copied such an image from a
contentEditable section and pasted it lower down the same section, would
it still have the image?).

We could define that it returns an empty src attribute, which would
break the copy/paste example. That's the same behavior you'd get with
someone revoking the URL upon load anyway.

/ Jonas



To the point of reusability of blob url and actual existence of such 
URL, we must also consider non-media usage: a element, window.open, etc. 
I do see the ideal of preparing data with JS and letting them be 
displayed/downloaded using those methods as quite usefull and intuitive.


Brona

Re: [FileAPI] createObjectURL isReusable proposal

[Jonas Sicking]

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch wrote:
 On Thu, 2 Feb 2012, Arun Ranganathan wrote:

 2. Could we modify things so that img.src = blob is a reality? Mainly,
 if we modify things for the *most common* use case, that could be useful
 in mitigating some of our fears. Hixie, is this possible?

 Anything's possible, but I think the pain here would far outweigh the
 benefits. There would be some really hard questions to answer, too (e.g.
 what would innerHTML return? If you copied such an image from a
 contentEditable section and pasted it lower down the same section, would
 it still have the image?).

We could define that it returns an empty src attribute, which would
break the copy/paste example. That's the same behavior you'd get with
someone revoking the URL upon load anyway.

/ Jonas