On Mon, Apr 9, 2012 at 3:52 PM, Feras Moussa fer...@microsoft.com wrote:
We agree that the spec text should be updated to more clearly define what
dereference means.
When we were trying to solve this problem, we looked for a simple and
consistent way that a developer can understand what
, March 29, 2012 1:03 AM
To: Glenn Maynard
Cc: Jonas Sicking; public-webapps WG
Subject: 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
On Mon, Apr 9, 2012 at 5:52 PM, Feras Moussa fer...@microsoft.com wrote:
We agree that the spec text should be updated to more clearly define what
dereference means.
When we were trying to solve this problem, we looked for a simple and
consistent way that a developer can understand what
2012/3/29 Bronislav Klučka bronislav.klu...@bauglir.com
If I understand you, you find it problematic that by using weak ref, URL
would for some time reference actual Blob and other time it would not?
The problem is that the following code might or might not work, depending
on the behavior of
On 30.3.2012 15:21, Glenn Maynard wrote:
2012/3/29 Bronislav Klučka bronislav.klu...@bauglir.com
mailto:bronislav.klu...@bauglir.com
If I understand you, you find it problematic that by using weak
ref, URL would for some time reference actual Blob and other time
it would not?
2012/3/30 Bronislav Klučka bronislav.klu...@bauglir.com
url = createObjectURL(blob);
blob = null;
setTimeout(function() { img.src = url; }, 0);
That should not be problematic; yes, GC may actually free that blob
allocated memory later than that timeout function triggers, but there is
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
On Tue, Mar 27, 2012 at 4:59 PM, Glenn Maynard gl...@zewt.org wrote:
I didn't realize this was actually added to the spec:
The optional options dictionary argument contains a key, oneTimeOnly that
defaults to false. If set to true, then the first time the Blob URI is
dereferenced, user agents
On Wed, 28 Mar 2012 08:19:55 +0100, Jonas Sicking jo...@sicking.cc wrote:
I think we need to define that APIs like xhr.open(...) and the img.src
setter synchronously dereference the URL before returning.
What does dereferencing mean exactly? xhr.open() resolves URLs currently
and then
On Wed, Mar 28, 2012 at 2:17 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 28 Mar 2012 08:19:55 +0100, Jonas Sicking jo...@sicking.cc wrote:
I think we need to define that APIs like xhr.open(...) and the img.src
setter synchronously dereference the URL before returning.
What does
On Wed, 28 Mar 2012 10:51:59 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Mar 28, 2012 at 2:17 AM, Anne van Kesteren ann...@opera.com
wrote:
What does dereferencing mean exactly?
It means initiating the load or some such. Implementation-wise for
blob URLs it would likely mean going
On Wed, Mar 28, 2012 at 2:19 AM, Jonas Sicking jo...@sicking.cc wrote:
All of this will definitely be a lot of work to specify (and possibly
implement). But I don't see any other options to get interoperability
with Blobs and blob-URLs. It's definitely not a problem restricted to
oneTimeOnly.
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 defined. The idea is that microtasks can be queued (call
it queue a microtask), and the microtask queue is executed by the event
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
yet been properly defined. The idea is that microtasks can be queued (call
On Wed, Mar 28, 2012 at 7:49 PM, Jonas Sicking jo...@sicking.cc wrote:
This would still require work in each URL-consuming spec, to define
taking a
reference to the underlying blob's data when it receives an object URL.
I
think this is inherent to the feature.
This is an interesting
24 matches
Mail list logo
