On 2012-03-28 20:23, Anne van Kesteren wrote:
On Wed, 28 Mar 2012 20:10:53 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/28/12 10:42 AM, Glenn Adams wrote:
Any use of DOMString to serve as a holder for arbitrary binary data
(including inflating from UTF-8 bytes into 16-bit code units),
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
On Thu, 29 Mar 2012 01:15:19 +0200, Cameron McCormack c...@mozilla.com
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
On Wed, Mar 28, 2012 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Mar 28, 2012 at 4:36 PM, Glenn Maynard gl...@zewt.org 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
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:
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 gl...@zewt.org
On Thu, Mar 29, 2012 at 12:36 PM, Glenn Maynard gl...@zewt.org 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
On Thu, Mar 29, 2012 at 2:29 AM, Darin Fisher da...@chromium.org 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
On 30.3.2012 0:19, Glenn Maynard wrote:
On Thu, Mar 29, 2012 at 2:29 AM, Darin Fisher da...@chromium.org
mailto:da...@chromium.org wrote:
I've never been terribly happy with createObjectURL and the
requirement for
folks to remember to call revokeObjectURL. I really like that
2012/3/29 Bronislav Klučka bronislav.klu...@bauglir.com
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
On 30.3.2012 5:40, Glenn Maynard wrote:
2012/3/29 Bronislav Klučka bronislav.klu...@bauglir.com
mailto:bronislav.klu...@bauglir.com
Sure, weak referencing is probably not well explored approach, but
the underlying idea applied to blob is interesting: URL creates no
reference to
2012/3/29 Bronislav Klučka bronislav.klu...@bauglir.com
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
On 30.3.2012 5:54, Glenn Maynard wrote:
2012/3/29 Bronislav Klučka bronislav.klu...@bauglir.com
mailto:bronislav.klu...@bauglir.com
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
13 matches
Mail list logo
