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

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

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:

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 t

[fileapi] Pull Request on GitHub

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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24732 Bug 24732 depends on bug 21740, which changed state. Bug 21740 Summary: Guidance on DOMError and promises https://www.w3.org/Bugs/Public/show_bug.cgi?id=21740 What|Removed |Added --

[Bug 24732] Remove DOMError from FileAPI

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24732 Aryeh Gregor changed: What|Removed |Added Status|NEW |RESOLVED CC|

FileAPI | Programmatic Triggering of Downloads

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]

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

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

On 10/11/14 10:43 AM, Arthur Barstow wrote: If you are an Editor and you did not register for the meeting please note: a) If you can join the meeting via the teleconf bridge, please: 1) add your spec to the Potential Topics list and identify high priority discussion points; 2) plan to dial-in

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

[fileapi-directories-and-system/filewriter]

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

[Bug 24732] New: Remove DOMError from FileAPI

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

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

Re: [FileAPI] LC Comment Tracking

s include moving Blob URL to be redefined in terms of terminology in the WHATWG URL spec, in lieu of ABNFs. If you provide a dial-in on the day that you discuss File + FileSystem, I can try and dial in, but this depends on time. There will be others present from Mozilla :) The LC commentary is tr

[FileAPI] LC Comment Tracking

, etc. I am especially interested in whether or not you consider any of the bug fixes you applied as "substantive" and/or add a new feature (which would require a new LC). -Thanks, ArtB [1] <http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912> On 9/12/13 10:39 AM, ext Arthur

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 Las

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

[FileAPI]

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

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

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

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

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 h

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

, and it's all very cool, but there are a couple of > things that seem like they could work better. They might be things that are > too user agent specific for the spec (http://www.w3.org/TR/FileAPI/) to > comment on, but I thought I'd ask here and see if there's something I&#x

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

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

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

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 c

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

[FileAPI] Revisiting Deflate/Compression

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 p

[FileAPI]

Hello, I have a few suggestions (for Blob URL) for you, because in my experience, they should be part of the specification. *The events:* Currently it is not possible not to know if a Blob URL has been loaded by the browser, whether it is an image, a file download, etc.. For example, currently

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

ence<> here. Whenever you just > want to take a list of values in an operation argument, and you don't want to > keep a reference to a platform array object, you should use a sequence<>. Done. http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob -- A*

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

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

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

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 arra

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

; of the spec. > > Thanks for responding. > > Benjamin BERNARD > > > Le 12/08/2012 21:23, Jonas Sicking a écrit : >> On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD >> wrote: >>> Hi, >>> I was developing an offline music web App when I disco

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

that is no "Content-length" header specified here : http://www.w3.org/TR/FileAPI/#ProtocolExamples So when you play an audio/video file stored as a blob (under a blob URI) it's considered by the player as streaming content which means you can't get the duration of a song for instanc

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 store

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

Hi, I was developing an offline music web App when I discover that is no "Content-length" header specified here : http://www.w3.org/TR/FileAPI/#ProtocolExamples So when you play an audio/video file stored as a blob (under a blob URI) it's considered by the player as streamin

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

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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17277 Ms2ger changed: What|Removed |Added Status|NEW |RESOLVED CC|

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

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

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

[FileAPI] Deterministic release of Blob proposal

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 determin

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

[fileapi] timing of readyState changes vs. events

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

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

On Wed, Feb 29, 2012 at 3:43 PM, Glenn Adams wrote: > > HTML > > A conforming user > agent<http://dev.w3.org/2006/webapi/FileAPI/#dfn-conforming-implementation> > MUST > support at least the subset of the functionality defined in HTML that this > specification

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

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

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

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

  1   2   3   4   5   6   7   >