RE: [fileapi] Pull Request on GitHub

> 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

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 wo

Re: [fileapi] Pull Request on GitHub

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

Re: [fileapi] Pull Request on GitHub

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 els

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

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 al

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

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 w

Re: [FileAPI] LC Comment Tracking

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

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

Re: [FileAPI]

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 Work

Re: [FileAPI]

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

Re: [FileAPI]

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 fideli

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

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

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

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

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

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 d

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

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

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

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

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

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 ar

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

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 se

Re: [FileAPI] Revisiting Deflate/Compression

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

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

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

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

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

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

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

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

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

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 do

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

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

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

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

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 th

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

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 UR

Re: [FileAPI] File.slice spec bug

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() sp

Re: [FileAPI] File.slice spec bug

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

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

Re: [FileAPI] createObjectURL isReusable proposal

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 yo

Re: [FileAPI] Deterministic release of Blob proposal

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

Re: [FileAPI] Deterministic release of Blob proposal

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

Re: [FileAPI] Deterministic release of Blob proposal

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

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

RE: [FileAPI] Deterministic release of Blob proposal

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

Re: [FileAPI] Deterministic release of Blob proposal

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

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

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

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

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 ArrayBu

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

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(

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

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 y

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

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 u

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

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 mak

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

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 ex

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

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

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

Re: [FileAPI] Deterministic release of Blob proposal

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

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

RE: [FileAPI] Deterministic release of Blob proposal

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

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

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(

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

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 def

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

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

Re: [FileAPI] Deterministic release of Blob proposal

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

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

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

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

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 ha

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 no

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: - Original Message - > At TPAC we discussed the ability to deterministically

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

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

Re: [FileAPI] Deterministic release of Blob proposal

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

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

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

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 =

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

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

Re: [FileAPI] Deterministic release of Blob proposal

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; // ke

Re: [FileAPI] Deterministic release of Blob proposal

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 res

Re: [FileAPI] Deterministic release of Blob proposal

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

RE: [FileAPI] Deterministic release of Blob proposal

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

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.

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

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?

Re: [FileAPI] Deterministic release of Blob proposal

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

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

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

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

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 c

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

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

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

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 blo

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

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] createObjectURL isReusable proposal

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 t

Re: [FileAPI] createObjectURL isReusable proposal

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 imp

RE: [FileAPI] createObjectURL isReusable proposal

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

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

On Wed, Feb 29, 2012 at 3:43 PM, Glenn Adams wrote: > > HTML > > A conforming user > agent > MUST > support at least the subset of the functionality defined in HTML that this > specification relies upon; in particular, it mus

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

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 specifi

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

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 t

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

On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan 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 > he

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

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

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

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

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

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

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

On Tue, Feb 28, 2012 at 12:11 AM, Simon Pieters 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 wrote: > I agree that it "scrambles" the

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

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

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

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

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

On Tue, Feb 28, 2012 at 7:11 AM, Simon Pieters wrote: > On Tue, 28 Feb 2012 01:05:44 +0100, Glenn Maynard wrote: > >> On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan >> wrote: >> >>> Simon, >>> >>> Is the relevant part of HTML sufficient to refer to? >>> http://dev.w3.org/html5/spec/Overview.ht

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

On Tue, 28 Feb 2012 01:05:44 +0100, Glenn Maynard wrote: On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan wrote: Simon, Is the relevant part of HTML sufficient to refer to? http://dev.w3.org/html5/spec/Overview.html#utf-8 I was thinking of "If the data argument has any unpaired surrogates

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

On Tue, 28 Feb 2012 00:34:57 +0100, Arun Ranganathan wrote: Is the relevant part of HTML sufficient to refer to? http://dev.w3.org/html5/spec/Overview.html#utf-8 That is UTF-8 octets -> Unicode code points. UTF-16 -> UTF-8 is different. You want the algorithm in Web IDL that takes a DOMSt

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

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

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

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

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

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 wrote: > Thanks Glenn and Simon--I'll see what I can do. > > > On Fri, Sep 23, 2011 at 1:34 AM,

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

Re: [FileAPI] createObjectURL isReusable proposal

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

Re: [FileAPI] createObjectURL isReusable proposal

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

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

Re: [FileAPI] Various comments

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

Re: [FileAPI] createObjectURL isReusable proposal

On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson 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

  1   2   3   4   5   6   >