Re: File API "oneTimeOnly" is too poorly defined

On 30.3.2012 5:54, Glenn Maynard wrote: 2012/3/29 Bronislav Klučka > The point was not to talk about weak refs, but about not creating a GC reference from URL to Blob If the lifetime of the URL is tied to the lifetime of the Blob, then that's wha

Re: File API "oneTimeOnly" is too poorly defined

2012/3/29 Bronislav Klučka > The point was not to talk about weak refs, but about not creating a GC > reference from URL to Blob > If the lifetime of the URL is tied to the lifetime of the Blob, then that's what a weak reference *is*. -- Glenn Maynard

Re: File API "oneTimeOnly" is too poorly defined

On 30.3.2012 5:40, Glenn Maynard wrote: 2012/3/29 Bronislav Klučka > Sure, weak referencing is probably not well explored approach, but the underlying idea applied to blob is interesting: URL creates no reference to Blob (from GC perspective), m

Re: File API "oneTimeOnly" is too poorly defined

2012/3/29 Bronislav Klučka > Sure, weak referencing is probably not well explored approach, but the > underlying idea applied to blob is interesting: URL creates no reference to > Blob (from GC perspective), meaning Blob is subjected to GC regardless of > BlobUrl existence. This would remove the

Re: File API "oneTimeOnly" is too poorly defined

On 30.3.2012 0:19, Glenn Maynard wrote: On Thu, Mar 29, 2012 at 2:29 AM, Darin Fisher > wrote: I've never been terribly happy with createObjectURL and the requirement for folks to remember to call revokeObjectURL. I really like that we're talking

Re: File API "oneTimeOnly" is too poorly defined

On Thu, Mar 29, 2012 at 2:29 AM, Darin Fisher wrote: > I've never been terribly happy with createObjectURL and the requirement for > folks to remember to call revokeObjectURL. I really like that we're > talking > about ways to minimize this pain :-) > > I noticed the WeakRefs proposal: > http://

Re: File API "oneTimeOnly" is too poorly defined

On Thu, Mar 29, 2012 at 12:36 PM, Glenn Maynard wrote: > oneTimeOnly (a poor name in this proposal) would simply queue a microtask > to revoke the URL. > > This is simpler, and answers a lot of questions. It means you can use the > URL as many times as you want synchronously, since it's not rele

Re: File API "oneTimeOnly" is too poorly defined

Any feedback on what exists in modern implementations? MS seems to have the most hard-line stance when talking about this API. When it comes to it, we ought to look at what happened in the latest harvest. IE10, O12, C19, and so forth. On Mar 28, 2012, at 6:12 PM, Glenn Maynard wrote: > On W

Re: File API "oneTimeOnly" is too poorly defined

On 29.3.2012 9:29, Darin Fisher wrote: I've never been terribly happy with createObjectURL and the requirement for folks to remember to call revokeObjectURL. I really like that we're talking about ways to minimize this pain :-) I noticed the WeakRefs proposal: http://wiki.ecmascript.org/dok

Re: File API "oneTimeOnly" is too poorly defined

On Wed, Mar 28, 2012 at 5:49 PM, Jonas Sicking wrote: > On Wed, Mar 28, 2012 at 4:36 PM, Glenn Maynard wrote: > > Here's another proposal, which is an iteration of the previous. It's > based > > on the "microtask" concept, which is creeping up here and there but > hasn't > > yet been properly d

Re: [xhr] statusText is underdefined

On Thu, 29 Mar 2012 01:15:19 +0200, Cameron McCormack wrote: OK, so just like DOMString is a "raw 16 bit word sequence" string, this new type would be a raw 8 bit byte sequence string. ByteString sounds like a good name for it. (Although it may be inconsistent with "octet" being unsigned

Re: [xhr] statusText is underdefined

On 2012-03-28 10:57, Boris Zbarsky wrote: On 3/28/12 2:48 AM, Anne van Kesteren wrote: Wow, "inflating" is what the specification currently requires for header fields, for what it's worth. Yes, Gecko has different behavior here for the status text and for header fields. I have no idea whether