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

/webapi/WebIDL/#dfn-obtain-unicode). This actually seems to take care of unmatched surrogates from UTF-16 when you use a UTF-8 decoding on the Unicode characters following the algorithmic conversion, and so we may have what we need here. This is the 29th February Editor's Draft (ensure you

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

d in endings. > >>> > >>> It doesn't elaborate any further.  The conversion from UTF-16 to > >>> UTF-8 > >>> needs > >>> to be defined, in particular for the edge case of invalid UTF-16 > >>> surrogates.  If this is already

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

f this is already defined somewhere, it isn't referenced. >>> >>> I suppose this would belong in "Common infrastructure", next to the >>> existing >>> section on UTF-8, not in FileAPI itself. >> >> >> WebSocket send() throws SYNTAX_ERR if its argument contains unpaired >> surrogates. It would be nice to be consistent. >> >> -- >> Simon Pieters >> Opera Software >> >

Re: Bug in http://dev.w3.org/2006/webapi/FileAPI

Pablo Moyano: In section "Editorial Note" under "Abstract", it says This is revision $Id: Overview.html,v 1.119 2012-02-20 18:29:29 arangana Exp $. i think the "$id" is a programming error of this webpage No, it's just an automatically inserted CVS $Id$ tag listing the revision of the file.

Bug in http://dev.w3.org/2006/webapi/FileAPI

In section "Editorial Note" under "Abstract", it says This is revision $Id: Overview.html,v 1.119 2012-02-20 18:29:29 arangana Exp $. i think the "$id" is a programming error of this webpage Regards

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

Re: [FileAPI] createObjectURL isReusable proposal

On 14.2.2012 15:20, Glenn Maynard wrote: 2012/2/14 Bronislav Klučka > The point of reusable Blob URL is the compatibility with regular URL, not having reusable URL would create unpleasant dichotomy in data manipulating... The point is avoiding

Re: [FileAPI] createObjectURL isReusable proposal

2012/2/14 Bronislav Klučka > The point of reusable Blob URL is the compatibility with regular URL, not > having reusable URL would create unpleasant dichotomy in data > manipulating... > The point is avoiding the error-prone need to release resources by hand. -- Glenn Maynard

Re: [FileAPI] createObjectURL isReusable proposal

On 14.2.2012 14:39, Charles Pritchard wrote: On 2/14/2012 5:35 AM, Bronislav Klučka wrote: 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?

Re: [FileAPI] createObjectURL isReusable proposal

On 2/14/2012 5:35 AM, Bronislav Klučka wrote: 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 commo

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

Re: [FileAPI] createObjectURL isReusable proposal

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 some of our fears. Hixie, is th

[FileAPI] Various comments

Hi Arun, I've read the File API specification, and have a number of comments: == 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. This paragraph is inconsistent about linking File

[FileAPI] RfC of pre-LC version; deadline Feb 24

Arun's latest updates to File API means the spec is very close to being ready for Last Call WD. As such, this is a Request for Comments of a pre-LC version of the spec using the latest ED as the basis: http://dev.w3.org/2006/webapi/FileAPI/ Please review the latest ED (above) now and

Re: [FileAPI] No streaming semantics?

Use slice; webkitSlice. They just it themselves put together on the media Apis as well. So that's cool. There's an append stream semantic. -Charles On Feb 5, 2012, at 5:18 PM, Justin Summerlin wrote: > I've been playing around with the FileAPI in both Chrome and Fi

[FileAPI] No streaming semantics?

I've been playing around with the FileAPI in both Chrome and Firefox. The API presented works very well for small files consistent with perhaps circa 1990s web usage. Previewing small images (~50K), reading and processing small files ("a few" MB) have been cases where uniformly

Re: [FileAPI] createObjectURL isReusable proposal

If you can't be civil, I'm not going to discuss with you. 2012/2/4 Bronislav Klučka > > > On 4.2.2012 5:55, Glenn Maynard wrote: > >> 2012/2/3 Bronislav Klučka > Bronislav.Klucka@**bauglir.com >> >> >> >>How would you create copies programmaticaly? How would you >>reassign src attribute

Re: [FileAPI] createObjectURL isReusable proposal

On 4.2.2012 5:55, Glenn Maynard wrote: 2012/2/3 Bronislav Klučka > How would you create copies programmaticaly? How would you reassign src attribute of one image to another? The idea, that sometimes the attribute would return string (regular URL

Re: [FileAPI] createObjectURL isReusable proposal

2012/2/3 Bronislav Klučka > How would you create copies programmaticaly? How would you reassign src > attribute of one image to another? The idea, that sometimes the attribute > would return string (regular URL, FileSystem APi URL) sometimes Blob... > What would you do in case like this > > img.

Re: [FileAPI] Blob protocol version - is this needed?

nk that would be the right move. I don't think there's > a way to > test it (and as I mentioned in my previous note our implementation > doesn't > have it). (Done). http://dev.w3.org/2006/webapi/FileAPI/ -- A*

Re: [FileAPI] createObjectURL isReusable proposal

On 3.2.2012 15:13, Anne van Kesteren wrote: On Thu, 02 Feb 2012 22:40:12 +0100, 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

Re: [FileAPI] createObjectURL isReusable proposal

On Thu, 02 Feb 2012 22:40:12 +0100, 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 some of our fears. Hixie, is this poss

Re: [FileAPI] createObjectURL isReusable proposal

On 3.2.2012 8:24, Charles Pritchard wrote: On 2/2/12 11:08 PM, Bronislav Klučka wrote: On 3.2.2012 7:51, Charles Pritchard wrote: I see no reason why an author should expect to stash 100MB of objects into createObjectURL, nor any reason why a UA could not manage 100MB for the application lif

Re: [FileAPI] createObjectURL isReusable proposal

On 2/2/12 11:08 PM, Bronislav Klučka wrote: On 3.2.2012 7:51, Charles Pritchard wrote: I see no reason why an author should expect to stash 100MB of objects into createObjectURL, nor any reason why a UA could not manage 100MB for the application lifetime; the user can certainly be informed, as

Re: [FileAPI] createObjectURL isReusable proposal

On 3.2.2012 7:51, Charles Pritchard wrote: On 2/2/12 10:40 PM, Bronislav Klučka wrote: On 3.2.2012 7:34, Bronislav Klučka wrote: On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: I'm not sure what a concret

Re: [FileAPI] createObjectURL isReusable proposal

On 2/2/12 10:40 PM, Bronislav Klučka wrote: On 3.2.2012 7:34, Bronislav Klučka wrote: On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: I'm not sure what a concrete proposal would look like. Maybe Element.URL

Re: [FileAPI] createObjectURL isReusable proposal

On 3.2.2012 7:34, Bronislav Klučka wrote: On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just Element.createObject

Re: [FileAPI] createObjectURL isReusable proposal

On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just Element.createObjectURL? Wouldn't returning an object (which can

Re: [FileAPI] createObjectURL isReusable proposal

On 2.2.2012 21:25, Arun Ranganathan wrote: Well, I'm a fan of img.src = blob being made a reality, *and* of the URL API being solidified. I'm not 100% sure how we can scope create* to an Element in the DOM. While open to a suggestion that clarifies your thoughts on this, I'm worried that

Re: [FileAPI] createObjectURL isReusable proposal

On Thu, Feb 2, 2012 at 4:48 PM, Charles Pritchard wrote: > Blob.prototype.toString=function(){ return URL.createObjectURL(this); > }; > We *really* don't want to make a function that gets automatically called "leak" memory like this. - Kyle

Re: [FileAPI] createObjectURL isReusable proposal

On Feb 2, 2012, at 1: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 some of our fears. Hixie, i

Re: [FileAPI] createObjectURL isReusable proposal

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 some of our fears. Hixie, is this possible? Anything's possible, but I think the pain

Re: [FileAPI] createObjectURL isReusable proposal

by how > easily > createObjectURL makes it to create web apps that accumulate mass > amounts of unreleased and unused memory. Most examples gloss over > revokeObjectURL entirely. I agree to the extent that minting Blob URLs for one-shot usage should be a non-default option, which is it i

RE: [FileAPI] Blob protocol version - is this needed?

On Tuesday, January 10, 2012 12:34 PM, Arun Ranganathan wrote: > Greetings Adrian, > > Sorry for the delay in responding to this email. > > Strictly speaking, we could remove the Blob Protocol Version (BLV) [1]. It > isn't returned in getAllResponseHeaders. BLV 's purpose was in case the > prot

Re: [FileAPI] createObjectURL isReusable proposal

quot;, there's specification laughing and throwing bricks at you. Again, the easiest way to handle that is to simply upload that image to server using AJAX, let URL be returned (regular http://) and no problem at all... There's been great progress in all regarding FileApi, but being able

Re: [FileAPI] createObjectURL isReusable proposal

On Sat, 28 Jan 2012, Kyle Huey wrote: > > Why though? What stops UAs from accepting the relevant objects for .src > properties? You don't necessarily have an object, e.g. if you're using innerHTML or document.write(). -- Ian Hickson U+1047E)\._.,--,'``.fL

Fwd: Re: [FileAPI] createObjectURL isReusable proposal

Original Message Subject:Re: [FileAPI] createObjectURL isReusable proposal Date: Mon, 30 Jan 2012 17:51:55 +0100 From: Bronislav Klučka To: Boris Zbarsky On 30.1.2012 17:29, Boris Zbarsky wrote: On 1/30/12 11:15 AM, Bronislav Klučka wrote: In this case

Re: [FileAPI] createObjectURL isReusable proposal

On 1/30/12 11:44 AM, Bronislav Klučka wrote: Both could be solved by Blob.URL, there is no strange string somehow connected to blob. Blob belongs to URL and URL belongs to blob... who cares how exactly is the string created (split -> join), it is string identification, not pointer reference...

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 17:29, Boris Zbarsky wrote: On 1/30/12 11:15 AM, Bronislav Klučka wrote: In this case you got me... what sense does it make? If there is no reference to original blob or any other object using that URL, why is it kept? Because given a string there is no way to tell whether someo

Re: [FileAPI] createObjectURL isReusable proposal

On 1/30/12 11:15 AM, Bronislav Klučka wrote: In this case you got me... what sense does it make? If there is no reference to original blob or any other object using that URL, why is it kept? Because given a string there is no way to tell whether someone has a "reference" it. Consider this:

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/30 Bronislav Klučka > so just a line > URL.createObjectUrl(blob) > creates a memory leak? Heh? > > Which brink me to my previous question, what happened to Blob.URL? Just > brink it back and this whole conversation can go away... > The only way blob.URL differs from URL.createObjectUrl is

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 16:56, Boris Zbarsky wrote: On 1/30/12 10:40 AM, Bronislav Klučka wrote: img1 = document.getElementById("my-image"); img1.src = URL.createObjectUrl(myBlob); img2.src = img1.src; should work like a charm and the URL and blob will be released as soon as all references will be 0 (des

Re: [FileAPI] createObjectURL isReusable proposal

On 1/30/12 10:40 AM, Bronislav Klučka wrote: img1 = document.getElementById("my-image"); img1.src = URL.createObjectUrl(myBlob); img2.src = img1.src; should work like a charm and the URL and blob will be released as soon as all references will be 0 (destroying the image) No, it won't. As curre

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 16:14, Glenn Maynard wrote: 2012/1/30 Bronislav Klučka > And how? Using src attribute? that would have to be changed to accept both string and Blob object? What it would return on get operation? Libraries managing images (lightboxes

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/30 Bronislav Klučka > And how? Using src attribute? that would have to be changed to accept both > string and Blob object? What it would return on get operation? Libraries > managing images (lightboxes) would have to consider, what does src mean? Or > do you propose other attribute? What w

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 15:18, Glenn Maynard wrote: 2012/1/30 Bronislav Klučka > it would seem that you do not understand the point here... if we allow img.src = blob approach we would HAVE TO have memory management on language level as well, either UR

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/30 Bronislav Klučka > it would seem that you do not understand the point here... if we allow > img.src = blob approach we would HAVE TO have memory management on language > level as well, > either URL reference or blob must be freed/nulled/whatever somewhere. > This is not simple reference

Re: [FileAPI] createObjectURL isReusable proposal

On 30.1.2012 14:40, Kyle Huey wrote: 2012/1/28 Bronislav Klučka > img.src = blob; tells nothing about possible access to underlying data using URL identifier And I think that if we're concerned about the blob being "leaked" for the lifetime

Re: [FileAPI] createObjectURL isReusable proposal

2012/1/28 Bronislav Klučka > img.src = blob; > > tells nothing about possible access to underlying data using URL identifier > And I think that if we're concerned about the blob being "leaked" for the lifetime of the document (because the URL was never revoked) we should abandon the blob URL app

Re: [FileAPI] createObjectURL isReusable proposal

It's reference issue img.src = URL.createObjectUrl(blob) means, that you cannot GC that blob, because URL is just text representation of reference. img.src = URL.createObjectUrl(blob, true) means, that you can GC that blob, because once URL is dereferenced, it will not be dereferenced again (B

Re: [FileAPI] createObjectURL isReusable proposal

Why though? What stops UAs from accepting the relevant objects for .src properties? - Kyle On Sat, Jan 28, 2012 at 2:47 AM, Ian Hickson wrote: > On Sat, 28 Jan 2012, Kyle Huey wrote: > > On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher > wrote: > > > > > > I'm not sure what a concrete proposal w

Re: [FileAPI] createObjectURL isReusable proposal

On Fri, Jan 27, 2012 at 6:14 PM, Glenn Maynard wrote: > Something else that needs to be defined: does "xhr.open('GET', url)" > consume the URL, or does that only happen when xhr.send() is called? (I'm > not looking for the answer here, just giving an example of something that > needs to be clear

Re: [FileAPI] createObjectURL isReusable proposal

On 28.1.2012 7:10, Darin Fisher wrote: On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson > wrote: On Wed, 14 Dec 2011, Adrian Bateman wrote: > > [...] the first dereference of the URL revokes it. > > This means that you can do something like: > > im

Re: [FileAPI] createObjectURL isReusable proposal

On Sat, 28 Jan 2012, Kyle Huey wrote: > On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: > > > > I'm not sure what a concrete proposal would look like. Maybe > > Element.URL.createObjectURL or just Element.createObjectURL? > > Wouldn't returning an object (which can be GCd) be a better solu

Re: [FileAPI] createObjectURL isReusable proposal

On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher wrote: > I'm not sure what a concrete proposal would look like. Maybe > Element.URL.createObjectURL or just Element.createObjectURL? > Wouldn't returning an object (which can be GCd) be a better solution? - Kyle

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson wrote: > On Wed, 14 Dec 2011, Adrian Bateman wrote: > > > > [...] the first dereference of the URL revokes it. > > > > This means that you can do something like: > > > > imgElement.src = URL.createObjectURL(blob,false) > > > > and not worry about havin

Re: [FileAPI] createObjectURL isReusable proposal

On Fri, Jan 27, 2012 at 11:57 AM, Arun Ranganathan wrote: > I'd expect making this fully interoperable to be a complex problem. It > makes fetch order significant, where it currently isn't. > > For example, if two images have their @src attribute set to a URL one > after the other, what guarant

Re: [FileAPI] createObjectURL isReusable proposal

Glenn points out that the issues raised in this thread weren't totally taken to the mat. Once again, sorry for bad nesting in my response: > > We can certainly talk through some of these issues, though the > > amount > > of > > > work we'd need to do doesn't go down. Our proposal is a small > >

Re: [FileAPI] Blob protocol version - is this needed?

ere I think we can remove this section. Thanks, Adrian [1] http://dev.w3.org/2006/webapi/FileAPI/#ProtocolName [2] http://dev.w3.org/2006/webapi/FileAPI/#ProtocolExamples

Re: [FileAPI] Remove readAsBinaryString?

On Monday, 19 December 2011 at 01:22, Charles Pritchard wrote: > I don't think it's practical for developers to follow the change logs. I've > certainly missed a few. > > While readAsBinaryString and readAsDataURL are very rarely used, it seems to > me that editors should take some extra eff

Re: [FileAPI] Remove readAsBinaryString?

ouragement? :) - Original Message - > Another topic that came up at TPAC was readAsBinaryString [1]. This > method > predates support for typed arrays in the FileAPI and allows binary > data > to be read and stored in a string. This is an inefficient way

Re: [FileAPI] Remove readAsBinaryString?

> as deprecated, which I suppose isn't strong enough discouragement? :) > > - Original Message - > > Another topic that came up at TPAC was readAsBinaryString [1]. This > > method > > predates support for typed arrays in the FileAPI and allows binary > > data > >

Re: [FileAPI] Length of the opaque string for blob URLs

- Original Message - > On Fri, Dec 16, 2011 at 3:13 PM, Michael Nordman > wrote: > > There is no requirement for that in the spec/draft, it's useful for > > our > > implementation. > > I suspect this will be true in Firefox too in due time. So I > definitely think that we should allow f

Re: [FileAPI] Length of the opaque string for blob URLs

On Fri, Dec 16, 2011 at 3:13 PM, Michael Nordman wrote: > There is no requirement for that in the spec/draft, it's useful for our > implementation. I suspect this will be true in Firefox too in due time. So I definitely think that we should allow for this. / Jonas

Re: [FileAPI] Length of the opaque string for blob URLs

There is no requirement for that in the spec/draft, it's useful for our implementation. On Fri, Dec 16, 2011 at 3:06 PM, Charles Pritchard wrote: > Is there something requiring that the origin be part of the URL? > > > > On Dec 16, 2011, at 2:29 PM, Michael Nordman wrote: > > > "and MUST be at

Re: [FileAPI] Length of the opaque string for blob URLs

Is there something requiring that the origin be part of the URL? On Dec 16, 2011, at 2:29 PM, Michael Nordman wrote: > > "and MUST be at least 36 characters long" > > I can't think of any reason for that requirement, seems fine to delete it. > > Webkit and Chrome do use guids but also embed

Re: [FileAPI] Length of the opaque string for blob URLs

> "and MUST be at least 36 characters long" I can't think of any reason for that requirement, seems fine to delete it. Webkit and Chrome do use guids but also embed the origin in these url. On Fri, Dec 16, 2011 at 5:58 AM, Jarred Nicholls wrote: > On Fri, Dec 16, 2011 at 6:27 AM, Anne van Kes

Re: [FileAPI] Length of the opaque string for blob URLs

On Fri, Dec 16, 2011 at 6:27 AM, Anne van Kesteren wrote: > On Fri, 16 Dec 2011 12:21:34 +0100, Arun Ranganathan < > aranganat...@mozilla.com> wrote: > >> Adrian: I'm willing to relax this. I suppose it *is* inconsistent to >> insist on 36 chars when we don't insist on UUID. But I suspect when

Re: [FileAPI] Remove readAsBinaryString?

On Fri, 16 Dec 2011 11:12:21 +0100, Charles Pritchard wrote: Wouldn't mind a more managed log of API shifts. Any ideas for a very simple deprecation journal? There's http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#historical for the DOM at the moment. I just learned about Can

Re: [FileAPI] Length of the opaque string for blob URLs

On Fri, 16 Dec 2011 12:21:34 +0100, Arun Ranganathan wrote: Adrian: I'm willing to relax this. I suppose it *is* inconsistent to insist on 36 chars when we don't insist on UUID. But I suspect when it comes time to making blob: a registered protocol (it was discussed on the IETF/URI lists

Re: [FileAPI] Length of the opaque string for blob URLs

with the recommendation to use UUIDs in the spec, > since it isn't a MUST I wonder whether the length requirement needs to > be a MUST. Could we relax this requirement? > > Thanks, > > Adrian > > [1] http://dev.w3.org/2006/webapi/FileAPI/#OpaqueStringDiscussion

Re: [FileAPI] Remove readAsBinaryString?

- Original Message - > Wouldn't mind a more managed log of API shifts. Any ideas for a very > simple deprecation journal? I'd be a fan of this. To date, the only thing I've deprecated (and will eventually remove) is readAsBinaryString. > > On topic: anyone using readAsBinaryString oug

Re: [FileAPI] createObjectURL isReusable proposal

Adrian, - Original Message - > At TPAC [1,2] I described our proposal for adding an isReusable flag > to > createObjectURL. A common pattern we have seen is the need for a blob > URL > for a single use (for example, loading into an element) and then > revoking the URL. This requires a fa

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011 11:25:38 +0100, Jonas Sicking wrote: On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren wrote: I think we should solve this by assigning an object directly to attributes that take a URL. So instead you would get imgElement.src = blob The problem is that we have tons

Re: [FileAPI] Remove readAsBinaryString?

readAsBinaryString [1]. This >> method >> predates support for typed arrays in the FileAPI and allows binary >> data >> to be read and stored in a string. This is an inefficient way to store >> data now that we have ArrayBuffer and we'd like to not support this >&g

Re: [FileAPI] Remove readAsBinaryString?

typed arrays in the FileAPI and allows binary > data > to be read and stored in a string. This is an inefficient way to store > data now that we have ArrayBuffer and we'd like to not support this > method. > > At TPAC I proposed that we remove readAsBinaryString from the

Re: [FileAPI] createObjectURL isReusable proposal

On 12/14/11 7:55 PM, Ian Hickson wrote: Browsers do keep them around for the lifetime of the page, in their HTTP cache. Browsers limit the size of the HTTP cache and evict as needed. -Boris

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 4:55 PM, Ian Hickson wrote: > On Wed, 14 Dec 2011, Glenn Maynard wrote: >> >> The problem isn't the cost of the URL mapping, it's the cost of keeping >> the backing Blob around.  If you drag around Google Maps for a long >> time, and it used object URLs to load its tile ima

Re: [FileAPI] createObjectURL isReusable proposal

On 12/14/2011 5:10 PM, Ian Hickson wrote: On Wed, 14 Dec 2011, Jonas Sicking wrote: On Wed, Dec 14, 2011 at 4:55 PM, Ian Hickson wrote: On Wed, 14 Dec 2011, Glenn Maynard wrote: The problem isn't the cost of the URL mapping, it's the cost of keeping the backing Blob around. If you drag aroun

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011, Jonas Sicking wrote: > On Wed, Dec 14, 2011 at 4:55 PM, Ian Hickson wrote: > > On Wed, 14 Dec 2011, Glenn Maynard wrote: > >> > >> The problem isn't the cost of the URL mapping, it's the cost of > >> keeping the backing Blob around.  If you drag around Google Maps for > >> a

Re: [FileAPI] createObjectURL isReusable proposal

On 12/14/2011 4:55 PM, Ian Hickson wrote: On Wed, 14 Dec 2011, Glenn Maynard wrote: The problem isn't the cost of the URL mapping, it's the cost of keeping the backing Blob around. If you drag around Google Maps for a long time, and it used object URLs to load its tile images, it'd be very bad

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011, Glenn Maynard wrote: > > The problem isn't the cost of the URL mapping, it's the cost of keeping > the backing Blob around. If you drag around Google Maps for a long > time, and it used object URLs to load its tile images, it'd be very bad > if the browser had to keep ever

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 7:40 PM, Ian Hickson wrote: > I think the better solution is to have implementations make keeping object > URLs defined be very cheap, so that nobody needs to ever release them. > The problem isn't the cost of the URL mapping, it's the cost of keeping the backing Blob aro

Re: [FileAPI] createObjectURL isReusable proposal

On Wed, 14 Dec 2011, Adrian Bateman wrote: > > [...] the first dereference of the URL revokes it. > > This means that you can do something like: > > imgElement.src = URL.createObjectURL(blob,false) > > and not worry about having to call URL.revokeObjectURL to release the > Blob. I think it's d

Re: [FileAPI] Remove readAsBinaryString?

On Wed, Dec 14, 2011 at 4:27 AM, Anne van Kesteren wrote: > On Wed, 14 Dec 2011 03:54:25 +0100, Jonas Sicking > wrote: > >> I agree we should remove it from spec! >> >> I think we'd be fine with removing it from the Firefox implementation. >> > > Same goes for Opera! Jonas & Anne, you just mad

<    1   2   3   4   5   6   7   >