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?

Re: [fileapi] Pull Request on GitHub

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

Re: [fileapi] Pull Request on GitHub

2016-08-16 Thread Arun Ranganathan
rent 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 t

[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-04-12 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24732 Aryeh Gregor changed: What|Removed |Added Status|NEW |RESOLVED

FileAPI | Programmatic Triggering of Downloads

2014-10-30 Thread Arun Ranganathan
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

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

2014-10-27 Thread Arun Ranganathan
On Oct 22, 2014, at 8:05 AM, Arthur Barstow art.bars...@gmail.com wrote: * File API: Arun and Jonas; which v1 bugs are blocking a new LC; what are next steps; timeline for LC. Arun, Jonas, Please see the above and respond accordingly. I am especially interested in the File API status

[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

[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

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

[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

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

Re: [FileAPI] LC Comment Tracking

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

[FileAPI] LC Comment Tracking

2013-11-07 Thread Arthur Barstow
. 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

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,

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

[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

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

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,

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

2013-10-04 Thread Brian Matthews (brmatthe)
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

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

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

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

2013-10-04 Thread Kyle Huey
, 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

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 http://file.name was specified in an HTTP request. Gecko does, because a bunch of servers send it. See

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

2013-10-04 Thread Brian Matthews (brmatthe)
, 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

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 m...@kylehuey.commailto:m...@kylehuey.com wrote: Second, and related, is what happens when someone saves an image or target of a link. In both cases with normal URLs, there's a name component and the user agent can use that as the name of the resulting file, or

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

[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

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.

[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

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

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

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

[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

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

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

2012-08-13 Thread Arun Ranganathan
BERNARD Le 12/08/2012 21:23, Jonas Sicking a écrit : On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD benjamin.bern...@benvii.com wrote: Hi, I was developing an offline music web App when I discover that is no Content-length header specified here : http://www.w3.org/TR/FileAPI

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 benjamin.bern...@benvii.com wrote: Hi, I was developing an offline music web App when I discover that is no Content-length header specified here : http://www.w3.org/TR/FileAPI/#ProtocolExamples So when you play an audio/video file stored

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 ms2...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC|

[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

Re: [FileAPI] createObjectURL isReusable proposal

2012-03-27 Thread Robert O'Callahan
On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch wrote: Anything's possible, but I think the pain here would far outweigh the benefits. There would be some really hard questions to answer, too (e.g. what would

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 jo...@sicking.cc wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch mailto:i...@hixie.ch wrote: Anything's possible, but I think the pain here would far outweigh the

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 fer...@microsoft.com wrote: In the case where close was called on a Blob that is being used in a pending request, then the request should be canceled. The expected result is the same as if abort() was called. It seems very weird that invoking

Re: [FileAPI] Deterministic release of Blob proposal

2012-03-08 Thread Glenn Maynard
On Wed, Mar 7, 2012 at 5:58 PM, Feras Moussa fer...@microsoft.com wrote: In the case where close was called on a Blob that is being used in a pending request, then the request should be canceled. The expected result is the same as if abort() was called. This would complicate every API that

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 fer...@microsoft.com wrote: xhr.send(blob); blob.close(); // method name TBD In our implementation, this case would fail. We think this is reasonable because the need for having a close() method is to allow deterministic release of the

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 gl...@zewt.org wrote: On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote: You can always call close() yourself, but Blob.close() should use the neuter mechanism already there, not make up a new one. Blobs aren't

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 k...@google.com wrote: On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote: You can always call close() yourself, but Blob.close() should use the neuter

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 k...@google.com wrote: On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote: You can always call close() yourself, but Blob.close() should use the neuter

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 k...@google.com wrote: On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock gbill...@google.com wrote: On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard ch...@jumis.com wrote: On 3/5/2012 5:56 PM, Glenn Maynard wrote: On Mon, Mar 5, 2012 at 7:04 PM,

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 ch...@jumis.com wrote: On Mar 7, 2012, at 11:38 AM, Kenneth Russell k...@google.com wrote: On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote: You

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 Pritchardch...@jumis.com wrote: On Mar 7, 2012, at 11:38 AM, Kenneth Russellk...@google.com wrote: I believe that we should fix the immediate problem and add a close() method to Blob. I'm not in favor of

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 ch...@jumis.com wrote: On 3/7/12 12:34 PM, Kenneth Russell wrote: On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchardch...@jumis.com  wrote: On Mar 7, 2012, at 11:38 AM, Kenneth Russellk...@google.com  wrote: I believe that we should fix the

Re: [FileAPI] Deterministic release of Blob proposal

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

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

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

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

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 ch...@jumis.com wrote: On 3/5/2012 5:56 PM, Glenn Maynard wrote: On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com wrote: Do you see old behavior working something like the following? var blob = new Blob(my new big blob);

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 fer...@microsoft.com wrote: At TPAC we discussed the ability to deterministically close

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

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 gbill...@google.com wrote: On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard ch...@jumis.com wrote: On 3/5/2012 5:56 PM, Glenn Maynard wrote: On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com wrote: Do you see old behavior working

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

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

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

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 k...@google.com wrote: A change like this would be feasible as long as it doesn't break compatibility. In other words, the current Transferable array would still need to be supported, but Transferable instances (or perhaps instances of some other

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 er...@google.com wrote: What about: XHR.send(blob); blob.close(); This is the same as: XHR.send(arrayBuffer); postMessage({foo: arrayBuffer}, [arrayBuffer]); which you can already do. Both of

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,

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 aranganat...@mozilla.com wrote: Ken, I'm not sure that adding close() to Transferable is a good idea. Not all Transferable types may want to support that explicit operation. What about adding close() to Blob, and having the neutering operation

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 k...@google.com wrote: On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan aranganat...@mozilla.com wrote: Ken, I'm not sure that adding close() to Transferable is a good idea. Not all Transferable types may want to support that explicit operation.

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

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

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

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.

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 micha...@google.com wrote: You can always call close() yourself, but Blob.close() should use the neuter mechanism already there, not make up a new one. Blobs aren't transferable, there is no existing mechanism that applies to them. Adding a

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.

RE: [FileAPI] Deterministic release of Blob proposal

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

Re: [FileAPI] Deterministic release of Blob proposal

2012-03-05 Thread Glenn Maynard
On Fri, Mar 2, 2012 at 6:54 PM, Feras Moussa fer...@microsoft.com wrote: To address this issue, we propose that a close method be added to the Blob interface. When called, the close method should release the underlying resource of the Blob, and future operations on the Blob

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 fer...@microsoft.com mailto:fer...@microsoft.com wrote: To address this issue, we propose that a close method be added to the Blob interface. When called, the close method should release

Re: [FileAPI] Deterministic release of Blob proposal

2012-03-05 Thread Glenn Maynard
On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com wrote: Do you see old behavior working something like the following? var blob = new Blob(my new big blob); var keepBlob = blob.slice(); destination.postMessage(blob, '*', [blob]); // is try/catch needed here? blob =

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 ch...@jumis.com mailto:ch...@jumis.com wrote: Do you see old behavior working something like the following? var blob = new Blob(my new big blob); var keepBlob = blob.slice();

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 er...@google.com wrote: On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren ann...@opera.com wrote: Uhm. What you need to do is queue a task that changes the state and fires the event. You cannot just fire an event from asynchronous operations.

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 ann...@opera.com wrote: On Fri, 02 Mar 2012 01:01:55 +0100, Eric U er...@google.com wrote: On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan aranganat...@mozilla.com wrote: OK, so the change is to ensure that these events are fired directly,

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 er...@google.com wrote: On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan aranganat...@mozilla.com wrote: OK, so the change is to ensure that these events are fired directly, and not queued, right? I'll make this change. This applies to

[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

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

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

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 aranganat...@mozilla.com wrote: Eric, In the readAsText in the latest draft [1] I see that readyState gets set to done When the blob has been read into memory fully. I see that elsewhere in the progress notification description, When the data

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

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

2012-02-29 Thread Arun Ranganathan
On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan aranganat...@mozilla.com wrote: or use another algorithm with an identical result, and be decoded as UTF-8. I think this can be removed. You can always replace algorithms with equivalent ones, in any part of an implementation. and be

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

2012-02-29 Thread Glenn Adams
On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan aranganat...@mozilla.comwrote: On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan aranganat...@mozilla.com wrote: Should the actual UTF-8 encoding algorithm be specified by HTML? I don't know, since I think that Unicode to UTF-8 is pretty

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

2012-02-29 Thread Arun Ranganathan
in FileAPI? Or can we merely say to encode as UTF-8 and leave it to implementations (a reasonable assumption IMHO). -- A*

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

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

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 gl...@skynav.com wrote: HTML A conforming user agenthttp://dev.w3.org/2006/webapi/FileAPI/#dfn-conforming-implementation MUST support at least the subset of the functionality defined in HTML that this specification relies upon; in particular

[fileapi] timing of readyState changes vs. events

2012-02-29 Thread Eric U
] http://dev.w3.org/2006/webapi/FileAPI/ [2] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0912.html

RE: [FileAPI] createObjectURL isReusable proposal

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

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-29 Thread Glenn Maynard
On Wed, Feb 29, 2012 at 9:38 PM, Feras Moussa fer...@microsoft.com wrote: Another case: whether loading a one-shot URL from a different origin, where you aren't allowed to load the content, still causes the URL to be revoked. (My first impression was that it shouldn't affect it at all, but

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

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

2012-02-28 Thread Jonas Sicking
On Tue, Feb 28, 2012 at 7:11 AM, Simon Pieters sim...@opera.com wrote: On Tue, 28 Feb 2012 01:05:44 +0100, Glenn Maynard gl...@zewt.org wrote: On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan aranganat...@mozilla.comwrote: Simon, Is the relevant part of HTML sufficient to refer to?

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

2012-02-28 Thread Simon Pieters
On Tue, 28 Feb 2012 13:05:37 +0100, Jonas Sicking jo...@sicking.cc wrote: If we can't U+FFFD unpaired surrogates on paste, I agree it makes sense to U+FFFD them in APIs. If the only way to get them is a JS escape, then an exception seems OK. People use JS strings to handle binary data. This

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

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

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

2012-02-28 Thread Glenn Maynard
On Tue, Feb 28, 2012 at 12:11 AM, Simon Pieters sim...@opera.com wrote: I think WebSocket should do the same, for the same reason. Have you filed a bug? (No, not until this conversation moves along a bit further.) On Tue, Feb 28, 2012 at 8:26 AM, Jonas Sicking jo...@sicking.cc wrote: I

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

2012-02-28 Thread Arun Ranganathan
here. This is the 29th February Editor's Draft (ensure you shift-reload if necessary): http://dev.w3.org/2006/webapi/FileAPI/ I'd appreciate a review. If this passes muster, we may be one step further along the way to deprecating BlobBuilder, which only stipulated writing out as UTF-8 when

  1   2   3   4   5   6   >