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

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:

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

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

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

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

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

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,

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 img src=blob:... and providing links to content using a href=blob: I've got it working, and it's all very cool, but there are a couple of

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 img src=blob:... and providing links to content using a href=blob: I've got it working, and it's all very cool,

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)
On Thu, Oct 3, 2013 at 5:35 PM, Brian Matthews (brmatthe) brmat...@cisco.commailto:brmat...@cisco.com wrote: I've been doing some prototyping around displaying images with img src=blob:... and providing links to content using a href=blob: I've got it working, and it's all very cool, but

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

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.

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

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

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

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

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

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

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

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 aranganat...@mozilla.comwrote: On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan aranganat...@mozilla.com wrote: On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan aranganat...@mozilla.com wrote: Should the actual UTF-8 encoding algorithm

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,

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

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

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

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

2012-02-27 Thread Eric U
What I can do is procrastinate until we agree that BlobBuilder is deprecated, and this is now the problem of the Blob constructor. Over to you, Arun and Jonas. On Mon, Sep 26, 2011 at 11:45 AM, Eric U er...@google.com wrote: Thanks Glenn and Simon--I'll see what I can do. On Fri, Sep 23,

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

2012-02-27 Thread Arun Ranganathan
Simon, Is the relevant part of HTML sufficient to refer to? http://dev.w3.org/html5/spec/Overview.html#utf-8 What I can do is procrastinate until we agree that BlobBuilder is deprecated, and this is now the problem of the Blob constructor. Over to you, Arun and Jonas. On Mon, Sep 26,

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

2012-02-27 Thread Glenn Maynard
On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan aranganat...@mozilla.comwrote: Simon, Is the relevant part of HTML sufficient to refer to? http://dev.w3.org/html5/spec/Overview.html#utf-8 That defines decoding UTF-8 to Unicode strings. You need the reverse. Using a replacement scheme

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

2012-02-27 Thread Anne van Kesteren
On Tue, 28 Feb 2012 00:34:57 +0100, Arun Ranganathan aranganat...@mozilla.com wrote: Is the relevant part of HTML sufficient to refer to? http://dev.w3.org/html5/spec/Overview.html#utf-8 That is UTF-8 octets - Unicode code points. UTF-16 - UTF-8 is different. You want the algorithm in Web

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

2012-02-27 Thread Simon Pieters
On Tue, 28 Feb 2012 01:05:44 +0100, Glenn Maynard gl...@zewt.org wrote: On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan aranganat...@mozilla.comwrote: Simon, Is the relevant part of HTML sufficient to refer to? http://dev.w3.org/html5/spec/Overview.html#utf-8 I was thinking of If the

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-24 Thread Arun Ranganathan
Bronislav, I could also go with reverse approach, with createObjectURL being oneTimeOnly by default createObjectURL(Blob aBlob, boolean? isPermanent) instead of current createObjectURL(Blob aBlob, boolean? isOneTime) the fact, that user would have to explicitly specify, that such URL is

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-24 Thread Bronislav Klučka
On 24.2.2012 20:12, Arun Ranganathan wrote: Bronislav, I could also go with reverse approach, with createObjectURL being oneTimeOnly by default createObjectURL(Blob aBlob, boolean? isPermanent) instead of current createObjectURL(Blob aBlob, boolean? isOneTime) the fact, that user would have

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-24 Thread Arun Ranganathan
On 24.2.2012 20:12, Arun Ranganathan wrote: Bronislav, I could also go with reverse approach, with createObjectURL being oneTimeOnly by default createObjectURL(Blob aBlob, boolean? isPermanent) instead of current createObjectURL(Blob aBlob, boolean? isOneTime) the fact, that

Re: [FileAPI] Various comments

2012-02-18 Thread Arun Ranganathan
Ms2ger, Many thanks for the detailed review. == 1. Introduction == Binary Large Object -- a name originally introduced to web APIs in Google Gears should use an en dash (—, U+2013) instead of two hyphens. Done. This paragraph is inconsistent about linking File and Blob to

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Bronislav Klučka
On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Charles Pritchard
On 2/14/2012 5:35 AM, Bronislav Klučka wrote: On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Bronislav Klučka
On 14.2.2012 14:39, Charles Pritchard wrote: On 2/14/2012 5:35 AM, Bronislav Klučka wrote: On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Glenn Maynard
2012/2/14 Bronislav Klučka bronislav.klu...@bauglir.com The point of reusable Blob URL is the compatibility with regular URL, not having reusable URL would create unpleasant dichotomy in data manipulating... The point is avoiding the error-prone need to release resources by hand. -- Glenn

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Bronislav Klučka
On 14.2.2012 15:20, Glenn Maynard wrote: 2012/2/14 Bronislav Klučka bronislav.klu...@bauglir.com mailto:bronislav.klu...@bauglir.com The point of reusable Blob URL is the compatibility with regular URL, not having reusable URL would create unpleasant dichotomy in data

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Bronislav Klučka
On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-13 Thread Jonas Sicking
On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in mitigating some of our fears. Hixie,

  1   2   3   4   5   >