RE: [fileapi] Pull Request on GitHub

2016-08-17 Thread 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

2016-08-17 Thread 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

2016-08-16 Thread 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

2016-08-16 Thread 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.



[fileapi] Pull Request on GitHub

2016-08-16 Thread Zhen Zhang
Hi,

I have a PR on GitHub regarding some issues of wording in current File API 
spec: https://github.com/w3c/FileAPI/pull/42 
<https://github.com/w3c/FileAPI/pull/42>, but nobody ever responded me there.
I wonder if I should discuss the patch somewhere else?

Thanks you,

- Zhen

[Bug 24732] Remove DOMError from FileAPI

2016-06-02 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24732
Bug 24732 depends on bug 21740, which changed state.

Bug 21740 Summary: Guidance on DOMError and promises
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21740

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug 24732] Remove DOMError from FileAPI

2016-04-12 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24732

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@aryeh.name
 Resolution|--- |MOVED

-- 
You are receiving this mail because:
You are on the CC list for the bug.


FileAPI | Programmatic Triggering of Downloads

2014-10-29 Thread Arun Ranganathan
WebAppsWG,

At the recent F2F, I received an ACTION to strike one of the use cases from the 
File API, since the File API itself did not deliver on that use case.

This is ACTION 750: https://www.w3.org/2008/webapps/track/actions/750 
which asks me to remove the use case, since there isn’t a mechanism to trigger 
programmatic downloads to the underlying OS filesystem.

But upon reflection, although FileAPI itself hasn’t provided any API surface 
for this, the recently finished HTML specification has given us something 
useful, but not implemented widely yet:
 
http://www.w3.org/TR/html5/links.html#attr-hyperlink-download

The use case itself calls for things such as storing assets for later use, 
including for use with third-party apps such as Calendar apps, which I’ve 
demonstrated using the Blob constructor and the “download” feature, since not 
everyone present at the meeting knew you could do this:

http://aruner.net/resources/BlobURL/datePickerForCal.html

In Firefox and Chrome (desktop) it works by triggering a download and invoking 
the Calendar application on your particular OS (Outlook 2013 on Windows or 
Calendar on Mac OS X). Safari shows the iCalendar entry “in the raw” and 
although Safari on iOS allows images that are Blob URLs to be downloaded, it 
doesn’t allow much to be done with other data types that are blob: URLs, such 
as iCalendar entries.

I don’t think I should remove the use case, but instead said that the actual 
requirement was handled in HTML, even if implementation status isn’t at 100%.

The File API provides additional guidance for File objects:

http://dev.w3.org/2006/webapi/FileAPI/#processing-media-types


— A*



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

2014-10-26 Thread Arun Ranganathan

On Oct 22, 2014, at 8:05 AM, Arthur Barstow  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*

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

2014-10-22 Thread Arthur Barstow

On 10/11/14 10:43 AM, Arthur Barstow wrote:
If you are an Editor and you did not register for the meeting please 
note:


a) If you can join the meeting via the teleconf bridge, please: 1) add 
your spec to the Potential Topics list and identify high priority 
discussion points; 2) plan to dial-in Monday morning (or let me know 
which open day + time slot you prefer to join the meeting).


b) If you cannot remotely participate in the meeting, please provide a 
short status of your spec, including any major blocking issues as well 
as general plans and expectations for the next six months (including 
publications plans). Please start a separate thread and use your 
spec's short name as the Subject: prefix (f.ex. "[html-imports] Oct 
2014 status report and plans").


Here is the list of specs whose Editor(s) did not register for the 
meeting (if I made any mistakes, I apologize in advance, but please do 
let me know):


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


-Thanks, ArtB


[Agenda] https://www.w3.org/wiki/Webapps/November2014Meeting





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

2014-04-02 Thread 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






[fileapi-directories-and-system/filewriter]

2014-04-02 Thread Eric U
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?].

  Eric



[Bug 24732] New: Remove DOMError from FileAPI

2014-02-19 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24732

Bug ID: 24732
   Summary: Remove DOMError from FileAPI
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
  Assignee: a...@mozilla.com
  Reporter: a...@mozilla.com
QA Contact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org

Bug 21740 specifies the long term direction of DOMError is to be removed
anyway; notably Bug 21740 Comment 11 suggests a way ahead without DOMError.  If
this is the long term direction of the web platform, we should remove it here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: [FileAPI] LC Comment Tracking

2013-11-21 Thread 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

2013-11-08 Thread 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/>
>> 
>> 
> 
> 




[FileAPI] LC Comment Tracking

2013-11-07 Thread Arthur Barstow

Hi Arun,

First, thanks for tracking the File API LC comments and for maintaining 
the comment tracking doc [1]!


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


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

2013-10-31 Thread 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]

2013-10-31 Thread 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]

2013-10-23 Thread 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
> 
> 
> 




[FileAPI]

2013-10-23 Thread psweatte

7.2 Interface File:
-add creationDate property
-add size property
-If the last modification date and time are not known, the attribute 
must return an empty string


8.3. Event Handler Attributes
-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

2013-10-07 Thread 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 ), 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*




[FileAPI] Question on order of calling onerror vs. setting error attribute

2013-10-04 Thread Brian Matthews (brmatthe)
[I tacked this on to another question but should have asked it separately, so 
here it is.]

In the File API spec, section 8.5.6, step 1 starts "Fire a progress event 
called error. Set the error attribute;". Doesn't firing an event call the event 
handler immediately (synchronously)? I followed through the links and 
references and it seems to, although I could have easily missed something. If 
it does, this seems to be saying to call the error handler *before* setting the 
error attribute, which seems backwards.

Thanks,
Brian


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

2013-10-04 Thread Brian Matthews (brmatthe)
On 10/4/13 7:54 AM, "Boris Zbarsky"  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 " 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] Questions on using Blobs for img src and a href

2013-10-04 Thread Brian Matthews (brmatthe)
On 10/4/13 7:48 AM, "Kyle Huey" mailto: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 
), 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.

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

2013-10-04 Thread Brian Matthews (brmatthe)


On Thu, Oct 3, 2013 at 5:35 PM, Brian Matthews (brmatthe) 
mailto:brmat...@cisco.com>> wrote:
I've been doing some prototyping around displaying images with  and providing links to content using . 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

2013-10-04 Thread 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 " 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

2013-10-04 Thread 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  src="blob:..."> and providing links to content using .
> 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 ), 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

2013-10-04 Thread 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  src="blob:..."> and providing links to content using .
> 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


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

2013-10-04 Thread Brian Matthews (brmatthe)
I've been doing some prototyping around displaying images with  and providing links to content using . 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.

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.

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

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.

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.

Thoughts?

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.

Thanks,
Brian


Re: [FileAPI] Revisiting Deflate/Compression

2013-07-15 Thread 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 :
> 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



[FileAPI] Revisiting Deflate/Compression

2013-07-13 Thread Charles Pritchard
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







[FileAPI]

2013-03-15 Thread Michaël Rouges
Hello,

I have a few suggestions (for Blob URL) for you, because in my experience, they
should be part of the specification.


*The events:*

Currently it is not possible not to know if a Blob URL has been loaded by
the browser, whether it is an image, a file download, etc..

For example, currently, I am developing a text editor allowing my users to
save their changes, using an anchor.

No method allows me to notify the user that the file has been saved (by
changing the color of the editor tab, for example, like Notepad++).

In addition, these events could be useful to ensure that the Blob URL is
loaded only once.


*The name of the file:*

A file name may likewise be very useful. I think a consideration of option
as BlobURL.name and/or based on the value of the download attribute of an
anchor to which the Blob URL is attached.


*The full path of the file:*

Currently, according to my tests on Firefox, I noticed the inability to
specify the full path of the file, converts all Firefox ":" & "/" by
underscores.

I am not suggesting that when the user clicks, the file is saved to the
specified path directly but offers a prompt browser to save the file to the
specified path, just like a Save as.

In my opinion, the full path chosen by the user should be able to be recovered,
for example, for monitoring the integrity of the application.

It should be specified, either by the download attribute value or by a Blob URL
property.



Well, that's all for now, if you have any questions, do not hesitate to
contact me, I will answer with pleasure.

Cordially,

Michaël Rouges


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

2012-09-13 Thread 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

2012-09-10 Thread 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

2012-09-10 Thread Boris Zbarsky

On 9/10/12 6:36 PM, Arun Ranganathan wrote:

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.


Sequence allows any WebIDL type as a sequence element.

So for example, you can do this:

  sequence<(sequence<(DOMString or Element or ArrayBufferView)> or
DOMString)>

Not that you should do such a thing.  ;)

-Boris



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

2012-09-10 Thread 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.

-- A*

On Sep 9, 2012, at 2:31 PM, Boris Zbarsky wrote:

> 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 sequence 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 constructor should probably take a sequence, not an IDL array object

2012-09-09 Thread 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 sequence 
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 constructor should probably take a sequence, not an IDL array object

2012-09-09 Thread Glenn Maynard
On Sun, Sep 9, 2012 at 9:34 AM, Boris Zbarsky  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.  Unless your internal
Blob representation is the same as the array you receive from your Blob
ctor binding, you're going to end up making another copy anyway.  (For
example, you may be storing the underlying representations of the data
rather than the JavaScript Blob objects themselves.)  I'd also expect
implementations to want to flatten other Blobs, so they don't need to be
recursive.  If you're passed [blob1, blob2], and blob1 itself is actually
[blobA, blobB], you'd be storing [blobA, blobB, blob2], so there's no point
in copying [blob1, blob2].

(Though both ways, this seems like an implementation detail.  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".)

-- 
Glenn Maynard


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

2012-09-09 Thread Boris Zbarsky
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.


But worse yet, actual real-life callers call this with JS arrays.  So 
the current IDL forces creation of a new WebIDL array object which is 
then thrown away because Blob makes a copy of the data anyway.  Seems 
like a waste.


-Boris



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

2012-08-13 Thread 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
>>   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

2012-08-12 Thread Benjamin BERNARD
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
  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

2012-08-12 Thread Jonas Sicking
On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD
 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



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

2012-08-12 Thread Benjamin BERNARD

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.


Thanks in advance,

--
Benjamin BERNARD





Re: [FileAPI] File.slice spec bug

2012-06-26 Thread Simon Pieters

On Tue, 26 Jun 2012 00:44:15 +0200, Andy Hou  wrote:


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


Please use the new slice() spec without prefix.

https://bugzilla.mozilla.org/show_bug.cgi?id=725289
https://bugs.webkit.org/show_bug.cgi?id=78111

--
Simon Pieters
Opera Software



Re: [FileAPI] File.slice spec bug

2012-06-26 Thread 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


[Bug 17277] [FileAPI] It have no clear behavior about negative index of FileList.item

2012-06-01 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17277

Ms2ger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ms2...@gmail.com
 Resolution||INVALID

--- Comment #3 from Ms2ger  2012-06-01 07:38:41 UTC ---
WebKit bug. Converting to an 'unsigned long' should wrap modulo 2**32.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.



[Bug 17277] New: [FileAPI] It have no clear behavior about negative index of FileList.item

2012-05-31 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17277

   Summary: [FileAPI] It have no clear behavior about negative
index of FileList.item
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: li@intel.com
 QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org


>From current spec, http://www.w3.org/TR/FileAPI/#dfn-filelist
MUST return the indexth File object in the FileList. If there is no indexth
File object in the FileList, then this method must return null.
But when the index is negative number, string, null, or undefined and so on,
what should be returned, whether it should raise exception or return null
directly.

Currently, webkit based browser and firefox have the different behavior.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.



Re: [FileAPI] createObjectURL isReusable proposal

2012-03-27 Thread Bronislav Klučka



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

On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking  wrote:

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson 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] createObjectURL isReusable proposal

2012-03-27 Thread Robert O'Callahan
On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking  wrote:

> On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson  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] Deterministic release of Blob proposal

2012-03-08 Thread Glenn Maynard
On Wed, Mar 7, 2012 at 5:58 PM, Feras Moussa  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

2012-03-08 Thread Anne van Kesteren
On Thu, 08 Mar 2012 00:58:02 +0100, Feras Moussa   
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

2012-03-07 Thread 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: [FileAPI] Deterministic release of Blob proposal

2012-03-07 Thread 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 
> 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

2012-03-07 Thread 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

2012-03-07 Thread Eric U
On Tue, Mar 6, 2012 at 5:12 PM, Feras Moussa  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
>&g

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

2012-03-07 Thread Kenneth Russell
On Wed, Mar 7, 2012 at 1:00 PM, Charles Pritchard  wrote:
> On 3/7/12 12:34 PM, Kenneth Russell wrote:
>>
>> On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchard
>>  wrote:
>>>
>>> On Mar 7, 2012, at 11:38 AM, Kenneth Russell  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: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

2012-03-07 Thread Charles Pritchard

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

On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchard  wrote:

On Mar 7, 2012, at 11:38 AM, Kenneth Russell  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

2012-03-07 Thread Kenneth Russell
On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchard  wrote:
>
> On Mar 7, 2012, at 11:38 AM, Kenneth Russell  wrote:
>
>> On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard  wrote:
>>> On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman  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  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

2012-03-07 Thread Greg Billock
On Tue, Mar 6, 2012 at 1:18 PM, Kenneth Russell  wrote:
> On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock  wrote:
>> On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard  wrote:
>>> On 3/5/2012 5:56 PM, Glenn Maynard wrote:
>>>
>>> On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard  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 sequence 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 sequence 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

2012-03-07 Thread Charles Pritchard

On Mar 7, 2012, at 11:38 AM, Kenneth Russell  wrote:

> On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard  wrote:
>> On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman  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  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

2012-03-07 Thread Eric U
On Wed, Mar 7, 2012 at 11:38 AM, Kenneth Russell  wrote:
> On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard  wrote:
>> On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman  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  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

2012-03-07 Thread Kenneth Russell
On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard  wrote:
> On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman  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  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: [FileAPI] Deterministic release of Blob proposal

2012-03-07 Thread Anne van Kesteren
On Wed, 07 Mar 2012 02:12:39 +0100, Feras Moussa   
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

2012-03-06 Thread Glenn Maynard
On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman  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  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

2012-03-06 Thread 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

2012-03-06 Thread 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

2012-03-06 Thread 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 slic

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

2012-03-06 Thread Charles Pritchard
On Mar 6, 2012, at 2:25 PM, Kenneth Russell  wrote:

> On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan
>  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  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: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

2012-03-06 Thread Kenneth Russell
On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan
 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  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

2012-03-06 Thread 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: [FileAPI] Deterministic release of Blob proposal

2012-03-06 Thread Glenn Maynard
(I wish people wouldn't split threads.)

On Tue, Mar 6, 2012 at 2:29 PM, Eric U  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 
 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

2012-03-06 Thread Glenn Maynard
On Tue, Mar 6, 2012 at 3:18 PM, Kenneth Russell  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 
 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: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

2012-03-06 Thread 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  wrote:
> On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock  wrote:
>> On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard  wrote:
>>> On 3/5/2012 5:56 PM, Glenn Maynard wrote:
>>>
>>> On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard  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 sequence 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 sequence 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
>>

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

2012-03-06 Thread 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: [FileAPI] Deterministic release of Blob proposal

2012-03-06 Thread 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.s

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

2012-03-06 Thread Kenneth Russell
On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock  wrote:
> On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard  wrote:
>> On 3/5/2012 5:56 PM, Glenn Maynard wrote:
>>
>> On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard  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 sequence 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 sequence 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#t

Re: [FileAPI] Deterministic release of Blob proposal

2012-03-06 Thread 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  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  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
> >

Re: [FileAPI] Deterministic release of Blob proposal

2012-03-06 Thread 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  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: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

2012-03-06 Thread Greg Billock
On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard  wrote:
> On 3/5/2012 5:56 PM, Glenn Maynard wrote:
>
> On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard  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
>
>



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

2012-03-05 Thread Charles Pritchard

On 3/5/2012 5:56 PM, Glenn Maynard wrote:
On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard > 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] Deterministic release of Blob proposal

2012-03-05 Thread Glenn Maynard
On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard  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


Re: [FileAPI] Deterministic release of Blob proposal

2012-03-05 Thread Charles Pritchard

On 3/5/2012 3:59 PM, Glenn Maynard wrote:
On Fri, Mar 2, 2012 at 6:54 PM, Feras Moussa > 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

2012-03-05 Thread Glenn Maynard
On Fri, Mar 2, 2012 at 6:54 PM, Feras Moussa  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

2012-03-05 Thread 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
> >
> > inde

Re: [FileAPI] Deterministic release of Blob proposal

2012-03-05 Thread 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] timing of readyState changes vs. events

2012-03-03 Thread Anne van Kesteren

On Fri, 02 Mar 2012 23:31:38 +0100, Eric U  wrote:
On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren   
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] Deterministic release of Blob proposal

2012-03-02 Thread 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


[FileAPI] Deterministic release of Blob proposal

2012-03-02 Thread Feras Moussa
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] timing of readyState changes vs. events

2012-03-02 Thread Arun Ranganathan
Eric,

> On Fri, 02 Mar 2012 01:01:55 +0100, Eric U  wrote:
> > On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
> >  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] timing of readyState changes vs. events

2012-03-02 Thread Eric U
On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren  wrote:
> On Fri, 02 Mar 2012 01:01:55 +0100, Eric U  wrote:
>>
>> On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
>>  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

2012-03-01 Thread Anne van Kesteren

On Fri, 02 Mar 2012 01:01:55 +0100, Eric U  wrote:

On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
 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] timing of readyState changes vs. events

2012-03-01 Thread Eric U
On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
 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

2012-03-01 Thread 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] createObjectURL isReusable proposal

2012-02-29 Thread 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] createObjectURL isReusable proposal

2012-02-29 Thread Glenn Maynard
On Wed, Feb 29, 2012 at 9:38 PM, Feras Moussa  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

2012-02-29 Thread 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.
> 
> 



[fileapi] timing of readyState changes vs. events

2012-02-29 Thread Eric U
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.

Eric

[1] http://dev.w3.org/2006/webapi/FileAPI/
[2] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0912.html



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

2012-02-29 Thread Glenn Adams
On Wed, Feb 29, 2012 at 3:43 PM, Glenn Adams  wrote:

>
> HTML
>
> A conforming user 
> agent<http://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 
> loops<http://dev.w3.org/2006/webapi/FileAPI/#event-loops>
>  and event handler 
> attributes<http://dev.w3.org/2006/webapi/FileAPI/#event-handler-attributes>.
> [HTML <http://dev.w3.org/2006/webapi/FileAPI/#HTML>]
>
Ignore the above paragraph.


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

2012-02-29 Thread Glenn Adams
On Wed, Feb 29, 2012 at 2:58 PM, Arun Ranganathan
wrote:

> 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
10646<http://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*, , , 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
[HTML<http://dev.w3.org/2006/webapi/FileAPI/#HTML>
].


HTML

A conforming user
agent<http://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
loops<http://dev.w3.org/2006/webapi/FileAPI/#event-loops>
 and event handler
attributes<http://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

2012-02-29 Thread 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* 


  1   2   3   4   5   6   7   >