Re: XMLHttpRequest.responseBlob
On Fri, 30 Apr 2010 05:43:36 +0200, Jonas Sicking wrote: So we have Opera: Document.URL WebSocket.URL StorageEvent.url WebKit: Document.URL EventSource.URL WebSocket.URL StorageEvent.uri WebKit changed 'uri' to 'url'. Gecko: Document.URL File.url StorageEvent.url I don't know where to go from here. StorageEvent.url has shipped in multiple browsers (apparently IE also has StorageEvent.url). It seems less disruptive to change WebSocket and EventSource since they aren't as widely deployed. So we'll change WebSocket.URL to WebSocket.url. -- Simon Pieters Opera Software
Re: XMLHttpRequest.responseBlob
On Thu, 29 Apr 2010, Jonas Sicking wrote: > > > > It doesn't, hence why I think we should be consistent and call them > > all "URL". My point is that while I can understand that we can't > > change Document.URL, if we decide that consistency with something else > > is more important for one API, e.g. "File.url", then we really have no > > excuse for being inconsistent with new APIs as well. > > Again, I think this is a very weird definition of "consistent". I think > it's more consistent to follow the hundreds of other properties which > use camelCase, than the one that is upper case. Despite the fact that > the one uppercase one has the same name. So you're arguing that it should be .uRL? That's what camelCase would give us here. It's closer to .URL than .url, though. > So I think we should go with what's most memorable and most > consistent, which I argue is using lower case. I agree except for I would concluded that that is uppercase in this case. Acronyms in the platform are more often uppercase than lowercase (e.g. .innerHTML, .outerHTML, .responseXML, .URL, etc). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XMLHttpRequest.responseBlob
On Thu, 29 Apr 2010, Simon Pieters wrote: > > > > Can you change it back? We've implemented and written tests for > > WebSocket.URL. WebKit has implemented EventSource.URL and > > WebSocket.URL. > > Do you plan to implement the File API attribute as .URL also? http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0803.html That doesn't really answer the question. True. Obviously I would want File API to be consistent with the rest. Which we plan to implement probably depends on the result of this discussion. I asked some friends: What do you think it should be called? WebSocket.url or WebSocket.URL? A: url. I always write abbreviations in lowercase in code. B: No idea. C: url. If it's supposed to be camelCase. URL feels dumb. D: Ooh, hard. It's mixed today already. There's responseXML on XHR. URL looks better. Which would you expect if you were going to use it? A: No idea. B: URL. I don't know why, it just looks better. C: url I think. D: URL, from other languages and that it's an abbreviation. Two of them asked me what I thought myself. Me: I've argued for URL since there's document.URL. C: Well, if that's the case then it should definitely be called URL. D: So true! I didn't think of that one. -- Simon Pieters Opera Software
Re: XMLHttpRequest.responseBlob
On Thu, Apr 29, 2010 at 7:01 PM, Ian Hickson wrote: > On Wed, 28 Apr 2010, Jonas Sicking wrote: >> > >> > I really think we should make sure we end up with a consistent naming >> > scheme here. If Gecko is the only engine that's going to do .url >> > instead of .URL, then I'm happy to change it back (on the assumption >> > that Gecko will eventually be forced to change to match). However, it >> > would be a pretty mess if we ended up developing APIs in the same year >> > that had different cases for the same attributes. >> >> Out of curiosity, why does the year of the API matter? > > It doesn't, hence why I think we should be consistent and call them all > "URL". My point is that while I can understand that we can't change > Document.URL, if we decide that consistency with something else is more > important for one API, e.g. "File.url", then we really have no excuse for > being inconsistent with new APIs as well. Again, I think this is a very weird definition of "consistent". I think it's more consistent to follow the hundreds of other properties which use camelCase, than the one that is upper case. Despite the fact that the one uppercase one has the same name. >> The way I look at it is: if you tell 100 developers that there is a >> property named 'url' on these objects (i.e. tell them, not show them in >> writing), how many of them do you think will envision it written in >> upper case characters, and how many will envision it in lower case >> characters? > > I would have assumed uppercase, but I knew of Document.URL. > > In practice, though, the vast majority of APIs are learnt through > tutorials and documentation and visual presentations, surely. I don't > remember ever learning one aurally (notwithstanding someone telling me > what to type over my shoulder, but then they'd specify the case). So I'm > not convinced this is a convincing argument either way. The point is that once you've learned it, you'll be going off of your memory. For cases where the casing isn't intuitive it can be hard to remember the exact right casing. I know people have had trouble with getElementById (vs. getElementByID) and XMLHttpRequest (vs. XmlHttpRequest, or XMLHTTPRequest). I've personally had to remind people of the correct casing of these on several occasions. > So we have > > Opera: > Document.URL > WebSocket.URL > StorageEvent.url > > WebKit: > Document.URL > EventSource.URL > WebSocket.URL > StorageEvent.uri > > Gecko: > Document.URL > File.url > StorageEvent.url > > I don't know where to go from here. WebKit or Opera implementing File.URL > or renaming StorageEvent's attribute to URL would be a clincher. Right > now, Jonas does have a convincing argument in saying that, short of > Document.URL, Gecko's platform offering is more consistent. Given this, if we go with .url Opera will have to change one property, webkit three and Gecko none. If we go with .URL Opera will still have to change one property, webkit one and Gecko two. So equally many changes in both cases. So I think we should go with what's most memorable and most consistent, which I argue is using lower case. (Granted, I think counting property changes is pretty silly. Changing browsers is significantly easier at this early stage than having developers deal with in consistencies. So arguments about not changing browsers doesn't sway me much, arguments as to what is more consistent does). / Jonas
Re: XMLHttpRequest.responseBlob
On Wed, 28 Apr 2010, Jonas Sicking wrote:
> >
> > I really think we should make sure we end up with a consistent naming
> > scheme here. If Gecko is the only engine that's going to do .url
> > instead of .URL, then I'm happy to change it back (on the assumption
> > that Gecko will eventually be forced to change to match). However, it
> > would be a pretty mess if we ended up developing APIs in the same year
> > that had different cases for the same attributes.
>
> Out of curiosity, why does the year of the API matter?
It doesn't, hence why I think we should be consistent and call them all
"URL". My point is that while I can understand that we can't change
Document.URL, if we decide that consistency with something else is more
important for one API, e.g. "File.url", then we really have no excuse for
being inconsistent with new APIs as well.
> The way I look at it is: if you tell 100 developers that there is a
> property named 'url' on these objects (i.e. tell them, not show them in
> writing), how many of them do you think will envision it written in
> upper case characters, and how many will envision it in lower case
> characters?
I would have assumed uppercase, but I knew of Document.URL.
In practice, though, the vast majority of APIs are learnt through
tutorials and documentation and visual presentations, surely. I don't
remember ever learning one aurally (notwithstanding someone telling me
what to type over my shoulder, but then they'd specify the case). So I'm
not convinced this is a convincing argument either way.
On Thu, 29 Apr 2010, Simon Pieters wrote:
> > >
> > > Can you change it back? We've implemented and written tests for
> > > WebSocket.URL. WebKit has implemented EventSource.URL and
> > > WebSocket.URL.
> >
> > Do you plan to implement the File API attribute as .URL also?
>
> http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0803.html
That doesn't really answer the question.
> > Does anyone implement EventStorage.url, by the way? I noticed that one was
> > lowercase in the spec while I was doing the earlier change.
>
> You mean StorageEvent?
>
> javascript:alert('url' in StorageEvent.prototype)
>
> Opera: false
> Firefox: true
> Chrome: false
These results seem inaccurate.
I used these two test files to test the 'storage' event:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/464
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/465
It seems WebKit has a 'uri' attribute, and Opera has a 'url' attribute.
Firefox doesn't support , but using
window.addEventListener() shows it has a 'url' attribute also:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/466
So we have
Opera:
Document.URL
WebSocket.URL
StorageEvent.url
WebKit:
Document.URL
EventSource.URL
WebSocket.URL
StorageEvent.uri
Gecko:
Document.URL
File.url
StorageEvent.url
I don't know where to go from here. WebKit or Opera implementing File.URL
or renaming StorageEvent's attribute to URL would be a clincher. Right
now, Jonas does have a convincing argument in saying that, short of
Document.URL, Gecko's platform offering is more consistent.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XMLHttpRequest.responseBlob
On Thu, Apr 29, 2010 at 3:35 PM, Darin Fisher wrote: > On Thu, Apr 29, 2010 at 3:24 PM, Eric Uhrhane wrote: >> >> On Thu, Apr 29, 2010 at 3:04 PM, Darin Fisher wrote: >> > >> > >> > On Wed, Apr 28, 2010 at 2:30 PM, Eric Uhrhane wrote: >> >> >> >> On Wed, Apr 28, 2010 at 12:45 PM, Darin Fisher >> >> wrote: >> >> > On Wed, Apr 28, 2010 at 11:57 AM, Michael Nordman >> >> > >> >> > wrote: >> >> >> >> >> >> >> >> >> On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking >> >> >> wrote: >> >> >>> >> >> >>> Ugh, sent this originally to just Darin. Resending to the list. >> >> >>> >> >> >>> On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher >> >> >>> wrote: >> >> >>> > On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher >> >> >>> >> >> >> >>> >> wrote: >> >> >>> >> > On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking >> >> >>> >> > >> >> >>> >> > wrote: >> >> >>> >> >> >> >> >>> >> >> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher >> >> >>> >> >> >> >> >>> >> >> wrote: >> >> >>> >> >> >> It would be nice to be able to allow streaming such that >> >> >>> >> >> >> every >> >> >>> >> >> >> time >> >> >>> >> >> >> a >> >> >>> >> >> >> progress event is fired only the newly downloaded data is >> >> >>> >> >> >> available. >> >> >>> >> >> >> The UA is then free to throw away that data once the event >> >> >>> >> >> >> is >> >> >>> >> >> >> done >> >> >>> >> >> >> firing. This would be useful in the cases when the page is >> >> >>> >> >> >> able >> >> >>> >> >> >> to >> >> >>> >> >> >> do >> >> >>> >> >> >> incremental parsing of the resulting document. >> >> >>> >> >> >> >> >> >>> >> >> >> If we add a 'load mode' flag on XMLHttpRequest, which >> >> >>> >> >> >> can't >> >> >>> >> >> >> be >> >> >>> >> >> >> modified after send() is called, then streaming to a Blob >> >> >>> >> >> >> could >> >> >>> >> >> >> simply >> >> >>> >> >> >> be another enum value for such a flag. >> >> >>> >> >> >> >> >> >>> >> >> >> There is still the problem of how the actual blob works. >> >> >>> >> >> >> I.e. >> >> >>> >> >> >> does >> >> >>> >> >> >> .responseBlob return a new blob every time more data is >> >> >>> >> >> >> returned? Or >> >> >>> >> >> >> should the same Blob be constantly modifying? If >> >> >>> >> >> >> modifying, >> >> >>> >> >> >> what >> >> >>> >> >> >> happens to any in-progress reads when the file is >> >> >>> >> >> >> modified? >> >> >>> >> >> >> Or >> >> >>> >> >> >> do >> >> >>> >> >> >> you >> >> >>> >> >> >> just make the Blob available once the whole resource has >> >> >>> >> >> >> been >> >> >>> >> >> >> downloaded? >> >> >>> >> >> >> >> >> >>> >> >> > >> >> >>> >> >> > >> >> >>> >> >> > This is why I suggested using FileWriter. FileWriter >> >> >>> >> >> > already >> >> >>> >> >> > has >> >> >>> >> >> > to >> >> >>> >> >> > deal with >> >> >>> >> >> > most of the problems you mentioned above, >> >> >>> >> >> >> >> >>> >> >> Actually, as far as I can tell FileWriter is write-only so it >> >> >>> >> >> doesn't >> >> >>> >> >> deal with any of the problems above. >> >> >>> >> > >> >> >>> >> > When you use createWriter, you are creating a FileWriter to an >> >> >>> >> > existing >> >> >>> >> > File. >> >> >>> >> > The user could attempt to create a FileReader to the very same >> >> >>> >> > File >> >> >>> >> > while >> >> >>> >> > a FileWriter is open to it. >> >> >>> >> > It is true that for there is no way to get >> >> >>> >> > at >> >> >>> >> > the >> >> >>> >> > underlying >> >> >>> >> > File object. That is perhaps a good thing for the use case of >> >> >>> >> > downloading >> >> >>> >> > to >> >> >>> >> > a location specified by the user. >> >> >>> >> >> >> >>> >> Ah. But as far as I can tell (and remember), it's still fairly >> >> >>> >> undefined what happens when the OS file under a File/Blob object >> >> >>> >> is >> >> >>> >> mutated. >> >> >>> >> >> >> >>> >> / Jonas >> >> >>> > >> >> >>> > Agreed. I don't see it as a big problem. Do you? The >> >> >>> > application >> >> >>> > developer is >> >> >>> > in control. They get to specify the output file (via FileWriter) >> >> >>> > that >> >> >>> > XHR >> >> >>> > sends its >> >> >>> > output to, and they get to know when XHR is done writing. So, >> >> >>> > the >> >> >>> > application >> >> >>> > developer can avoid reading from the file until XHR is done >> >> >>> > writing. >> >> >>> >> >> >>> Well, it seems like a bigger deal here since the file is being >> >> >>> constantly modified as we're downloading data into it, no? So for >> >> >>> example if you grab a File object after the first progress event, >> >> >>> what >> >> >>> does that File object contain after the second? Does it contain the >> >> >>> whole file, including the newly downloaded data? Or does it contain >> >> >>> only the data after the first progress event? Or is the File object >> >> >>> now invalid and can't be used? >> >> >> >> >> >> What gears did about that was to provide a 'snapshot' of t
Re: XMLHttpRequest.responseBlob
On Thu, Apr 29, 2010 at 3:24 PM, Eric Uhrhane wrote: > On Thu, Apr 29, 2010 at 3:04 PM, Darin Fisher wrote: > > > > > > On Wed, Apr 28, 2010 at 2:30 PM, Eric Uhrhane wrote: > >> > >> On Wed, Apr 28, 2010 at 12:45 PM, Darin Fisher > wrote: > >> > On Wed, Apr 28, 2010 at 11:57 AM, Michael Nordman < > micha...@google.com> > >> > wrote: > >> >> > >> >> > >> >> On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking > >> >> wrote: > >> >>> > >> >>> Ugh, sent this originally to just Darin. Resending to the list. > >> >>> > >> >>> On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher > >> >>> wrote: > >> >>> > On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking > >> >>> > wrote: > >> >>> >> > >> >>> >> On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher < > da...@chromium.org> > >> >>> >> wrote: > >> >>> >> > On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking > > >> >>> >> > wrote: > >> >>> >> >> > >> >>> >> >> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher > >> >>> >> >> > >> >>> >> >> wrote: > >> >>> >> >> >> It would be nice to be able to allow streaming such that > >> >>> >> >> >> every > >> >>> >> >> >> time > >> >>> >> >> >> a > >> >>> >> >> >> progress event is fired only the newly downloaded data is > >> >>> >> >> >> available. > >> >>> >> >> >> The UA is then free to throw away that data once the event > is > >> >>> >> >> >> done > >> >>> >> >> >> firing. This would be useful in the cases when the page is > >> >>> >> >> >> able > >> >>> >> >> >> to > >> >>> >> >> >> do > >> >>> >> >> >> incremental parsing of the resulting document. > >> >>> >> >> >> > >> >>> >> >> >> If we add a 'load mode' flag on XMLHttpRequest, which can't > >> >>> >> >> >> be > >> >>> >> >> >> modified after send() is called, then streaming to a Blob > >> >>> >> >> >> could > >> >>> >> >> >> simply > >> >>> >> >> >> be another enum value for such a flag. > >> >>> >> >> >> > >> >>> >> >> >> There is still the problem of how the actual blob works. > I.e. > >> >>> >> >> >> does > >> >>> >> >> >> .responseBlob return a new blob every time more data is > >> >>> >> >> >> returned? Or > >> >>> >> >> >> should the same Blob be constantly modifying? If modifying, > >> >>> >> >> >> what > >> >>> >> >> >> happens to any in-progress reads when the file is modified? > >> >>> >> >> >> Or > >> >>> >> >> >> do > >> >>> >> >> >> you > >> >>> >> >> >> just make the Blob available once the whole resource has > been > >> >>> >> >> >> downloaded? > >> >>> >> >> >> > >> >>> >> >> > > >> >>> >> >> > > >> >>> >> >> > This is why I suggested using FileWriter. FileWriter > already > >> >>> >> >> > has > >> >>> >> >> > to > >> >>> >> >> > deal with > >> >>> >> >> > most of the problems you mentioned above, > >> >>> >> >> > >> >>> >> >> Actually, as far as I can tell FileWriter is write-only so it > >> >>> >> >> doesn't > >> >>> >> >> deal with any of the problems above. > >> >>> >> > > >> >>> >> > When you use createWriter, you are creating a FileWriter to an > >> >>> >> > existing > >> >>> >> > File. > >> >>> >> > The user could attempt to create a FileReader to the very same > >> >>> >> > File > >> >>> >> > while > >> >>> >> > a FileWriter is open to it. > >> >>> >> > It is true that for there is no way to get > at > >> >>> >> > the > >> >>> >> > underlying > >> >>> >> > File object. That is perhaps a good thing for the use case of > >> >>> >> > downloading > >> >>> >> > to > >> >>> >> > a location specified by the user. > >> >>> >> > >> >>> >> Ah. But as far as I can tell (and remember), it's still fairly > >> >>> >> undefined what happens when the OS file under a File/Blob object > is > >> >>> >> mutated. > >> >>> >> > >> >>> >> / Jonas > >> >>> > > >> >>> > Agreed. I don't see it as a big problem. Do you? The > application > >> >>> > developer is > >> >>> > in control. They get to specify the output file (via FileWriter) > >> >>> > that > >> >>> > XHR > >> >>> > sends its > >> >>> > output to, and they get to know when XHR is done writing. So, the > >> >>> > application > >> >>> > developer can avoid reading from the file until XHR is done > writing. > >> >>> > >> >>> Well, it seems like a bigger deal here since the file is being > >> >>> constantly modified as we're downloading data into it, no? So for > >> >>> example if you grab a File object after the first progress event, > what > >> >>> does that File object contain after the second? Does it contain the > >> >>> whole file, including the newly downloaded data? Or does it contain > >> >>> only the data after the first progress event? Or is the File object > >> >>> now invalid and can't be used? > >> >> > >> >> What gears did about that was to provide a 'snapshot' of the > >> >> downloaded data each time responseBlob was called, with > >> >> the 'snapshot' being consistent with the progress events > >> >> having been seen by the caller. The 'snapshot' would remain > >> >> valid until discarded by the caller. Each snapshot just provided > >> >> a view onto the same data which maybe was in memory or > >> >> maybe h
Re: XMLHttpRequest.responseBlob
On Thu, Apr 29, 2010 at 3:04 PM, Darin Fisher wrote: > > > On Wed, Apr 28, 2010 at 2:30 PM, Eric Uhrhane wrote: >> >> On Wed, Apr 28, 2010 at 12:45 PM, Darin Fisher wrote: >> > On Wed, Apr 28, 2010 at 11:57 AM, Michael Nordman >> > wrote: >> >> >> >> >> >> On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking >> >> wrote: >> >>> >> >>> Ugh, sent this originally to just Darin. Resending to the list. >> >>> >> >>> On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher >> >>> wrote: >> >>> > On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking >> >>> > wrote: >> >>> >> >> >>> >> On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher >> >>> >> wrote: >> >>> >> > On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking >> >>> >> > wrote: >> >>> >> >> >> >>> >> >> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher >> >>> >> >> >> >>> >> >> wrote: >> >>> >> >> >> It would be nice to be able to allow streaming such that >> >>> >> >> >> every >> >>> >> >> >> time >> >>> >> >> >> a >> >>> >> >> >> progress event is fired only the newly downloaded data is >> >>> >> >> >> available. >> >>> >> >> >> The UA is then free to throw away that data once the event is >> >>> >> >> >> done >> >>> >> >> >> firing. This would be useful in the cases when the page is >> >>> >> >> >> able >> >>> >> >> >> to >> >>> >> >> >> do >> >>> >> >> >> incremental parsing of the resulting document. >> >>> >> >> >> >> >>> >> >> >> If we add a 'load mode' flag on XMLHttpRequest, which can't >> >>> >> >> >> be >> >>> >> >> >> modified after send() is called, then streaming to a Blob >> >>> >> >> >> could >> >>> >> >> >> simply >> >>> >> >> >> be another enum value for such a flag. >> >>> >> >> >> >> >>> >> >> >> There is still the problem of how the actual blob works. I.e. >> >>> >> >> >> does >> >>> >> >> >> .responseBlob return a new blob every time more data is >> >>> >> >> >> returned? Or >> >>> >> >> >> should the same Blob be constantly modifying? If modifying, >> >>> >> >> >> what >> >>> >> >> >> happens to any in-progress reads when the file is modified? >> >>> >> >> >> Or >> >>> >> >> >> do >> >>> >> >> >> you >> >>> >> >> >> just make the Blob available once the whole resource has been >> >>> >> >> >> downloaded? >> >>> >> >> >> >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > This is why I suggested using FileWriter. FileWriter already >> >>> >> >> > has >> >>> >> >> > to >> >>> >> >> > deal with >> >>> >> >> > most of the problems you mentioned above, >> >>> >> >> >> >>> >> >> Actually, as far as I can tell FileWriter is write-only so it >> >>> >> >> doesn't >> >>> >> >> deal with any of the problems above. >> >>> >> > >> >>> >> > When you use createWriter, you are creating a FileWriter to an >> >>> >> > existing >> >>> >> > File. >> >>> >> > The user could attempt to create a FileReader to the very same >> >>> >> > File >> >>> >> > while >> >>> >> > a FileWriter is open to it. >> >>> >> > It is true that for there is no way to get at >> >>> >> > the >> >>> >> > underlying >> >>> >> > File object. That is perhaps a good thing for the use case of >> >>> >> > downloading >> >>> >> > to >> >>> >> > a location specified by the user. >> >>> >> >> >>> >> Ah. But as far as I can tell (and remember), it's still fairly >> >>> >> undefined what happens when the OS file under a File/Blob object is >> >>> >> mutated. >> >>> >> >> >>> >> / Jonas >> >>> > >> >>> > Agreed. I don't see it as a big problem. Do you? The application >> >>> > developer is >> >>> > in control. They get to specify the output file (via FileWriter) >> >>> > that >> >>> > XHR >> >>> > sends its >> >>> > output to, and they get to know when XHR is done writing. So, the >> >>> > application >> >>> > developer can avoid reading from the file until XHR is done writing. >> >>> >> >>> Well, it seems like a bigger deal here since the file is being >> >>> constantly modified as we're downloading data into it, no? So for >> >>> example if you grab a File object after the first progress event, what >> >>> does that File object contain after the second? Does it contain the >> >>> whole file, including the newly downloaded data? Or does it contain >> >>> only the data after the first progress event? Or is the File object >> >>> now invalid and can't be used? >> >> >> >> What gears did about that was to provide a 'snapshot' of the >> >> downloaded data each time responseBlob was called, with >> >> the 'snapshot' being consistent with the progress events >> >> having been seen by the caller. The 'snapshot' would remain >> >> valid until discarded by the caller. Each snapshot just provided >> >> a view onto the same data which maybe was in memory or >> >> maybe had spilled over to disk unbeknownst to the caller. >> >> >> >>> >> >>> I'm also still unsure that a FileWriter is what you want generally. If >> >>> you're just downloading temporary data, but data that happens to be so >> >>> large that you don't want to keep it in memory, you don't want to >> >>> bother the user asking for a location for that temporary file. N
Re: XMLHttpRequest.responseBlob
On Wed, Apr 28, 2010 at 2:30 PM, Eric Uhrhane wrote: > On Wed, Apr 28, 2010 at 12:45 PM, Darin Fisher wrote: > > On Wed, Apr 28, 2010 at 11:57 AM, Michael Nordman > > wrote: > >> > >> > >> On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking > wrote: > >>> > >>> Ugh, sent this originally to just Darin. Resending to the list. > >>> > >>> On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher > >>> wrote: > >>> > On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking > >>> > wrote: > >>> >> > >>> >> On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher > >>> >> wrote: > >>> >> > On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking > >>> >> > wrote: > >>> >> >> > >>> >> >> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher < > da...@chromium.org> > >>> >> >> wrote: > >>> >> >> >> It would be nice to be able to allow streaming such that every > >>> >> >> >> time > >>> >> >> >> a > >>> >> >> >> progress event is fired only the newly downloaded data is > >>> >> >> >> available. > >>> >> >> >> The UA is then free to throw away that data once the event is > >>> >> >> >> done > >>> >> >> >> firing. This would be useful in the cases when the page is > able > >>> >> >> >> to > >>> >> >> >> do > >>> >> >> >> incremental parsing of the resulting document. > >>> >> >> >> > >>> >> >> >> If we add a 'load mode' flag on XMLHttpRequest, which can't be > >>> >> >> >> modified after send() is called, then streaming to a Blob > could > >>> >> >> >> simply > >>> >> >> >> be another enum value for such a flag. > >>> >> >> >> > >>> >> >> >> There is still the problem of how the actual blob works. I.e. > >>> >> >> >> does > >>> >> >> >> .responseBlob return a new blob every time more data is > >>> >> >> >> returned? Or > >>> >> >> >> should the same Blob be constantly modifying? If modifying, > what > >>> >> >> >> happens to any in-progress reads when the file is modified? Or > >>> >> >> >> do > >>> >> >> >> you > >>> >> >> >> just make the Blob available once the whole resource has been > >>> >> >> >> downloaded? > >>> >> >> >> > >>> >> >> > > >>> >> >> > > >>> >> >> > This is why I suggested using FileWriter. FileWriter already > has > >>> >> >> > to > >>> >> >> > deal with > >>> >> >> > most of the problems you mentioned above, > >>> >> >> > >>> >> >> Actually, as far as I can tell FileWriter is write-only so it > >>> >> >> doesn't > >>> >> >> deal with any of the problems above. > >>> >> > > >>> >> > When you use createWriter, you are creating a FileWriter to an > >>> >> > existing > >>> >> > File. > >>> >> > The user could attempt to create a FileReader to the very same > File > >>> >> > while > >>> >> > a FileWriter is open to it. > >>> >> > It is true that for there is no way to get at > >>> >> > the > >>> >> > underlying > >>> >> > File object. That is perhaps a good thing for the use case of > >>> >> > downloading > >>> >> > to > >>> >> > a location specified by the user. > >>> >> > >>> >> Ah. But as far as I can tell (and remember), it's still fairly > >>> >> undefined what happens when the OS file under a File/Blob object is > >>> >> mutated. > >>> >> > >>> >> / Jonas > >>> > > >>> > Agreed. I don't see it as a big problem. Do you? The application > >>> > developer is > >>> > in control. They get to specify the output file (via FileWriter) > that > >>> > XHR > >>> > sends its > >>> > output to, and they get to know when XHR is done writing. So, the > >>> > application > >>> > developer can avoid reading from the file until XHR is done writing. > >>> > >>> Well, it seems like a bigger deal here since the file is being > >>> constantly modified as we're downloading data into it, no? So for > >>> example if you grab a File object after the first progress event, what > >>> does that File object contain after the second? Does it contain the > >>> whole file, including the newly downloaded data? Or does it contain > >>> only the data after the first progress event? Or is the File object > >>> now invalid and can't be used? > >> > >> What gears did about that was to provide a 'snapshot' of the > >> downloaded data each time responseBlob was called, with > >> the 'snapshot' being consistent with the progress events > >> having been seen by the caller. The 'snapshot' would remain > >> valid until discarded by the caller. Each snapshot just provided > >> a view onto the same data which maybe was in memory or > >> maybe had spilled over to disk unbeknownst to the caller. > >> > >>> > >>> I'm also still unsure that a FileWriter is what you want generally. If > >>> you're just downloading temporary data, but data that happens to be so > >>> large that you don't want to keep it in memory, you don't want to > >>> bother the user asking for a location for that temporary file. Nor do > >>> you want that file to be around once the user leaves the page. > >> > >> > >> I think the point about not requiring the caller to manage the 'file' > are > >> important. > >> > >>> > >>> Sure, if the use case is actually downloading and saving a file for > >>> the user to u
Re: StorageEvent.url (WAS: XMLHttpRequest.responseBlob)
On Thu, Apr 29, 2010 at 6:01 PM, Boris Zbarsky wrote:
> On 4/29/10 12:13 PM, Jeremy Orlow wrote:
>
>> The following script does not work for me in 3.6. Would love to know
>> what I'm doing wrong:
>>
>> window.onstorage = function() { alert("HI"); }
>> localStorage.foo = localStorage.foo + " ";
>>
>
> In Gecko storage events for a change in window X are fired at all windows
> _except_ X that use that localStorage.
>
> This is in fact what the spec says to do. See
> http://dev.w3.org/html5/webstorage/#localStorageEvent which says:
>
> When the setItem(), removeItem(), and clear() methods are called
> on a Storage object x that is associated with a local storage area,
> if the methods did something, then in every HTMLDocument object whose
> Window object's localStorage attribute's Storage object is
> associated with the same storage area, other than x, a
> storage event must be fired, as described below.
>
> (emphasis added).
Ugh. I'm an idiot. I implemented this change in WebKit and even brought it
up on list. :-) Thanks for pointing it out.
> I don't get anything on the error console or any alert. (Though it
>> works in Safari and Opera.)
>>
>
> Sounds like some bugs need to be filed on Safari and Opera.
>
It's already changed in WebKit, so I suspect the next version of Safari will
be fixed. Similarly, the next stable version of Chrome (which is about to
go to beta) does this. And I just filed a bug against opera.
Anyway, I already have a patch out to change from uri -> url. Sounds like
it's the right thing to do: https://bugs.webkit.org/show_bug.cgi?id=38331
J
Re: StorageEvent.url (WAS: XMLHttpRequest.responseBlob)
On 4/29/10 12:13 PM, Jeremy Orlow wrote:
The following script does not work for me in 3.6. Would love to know
what I'm doing wrong:
window.onstorage = function() { alert("HI"); }
localStorage.foo = localStorage.foo + " ";
In Gecko storage events for a change in window X are fired at all
windows _except_ X that use that localStorage.
This is in fact what the spec says to do. See
http://dev.w3.org/html5/webstorage/#localStorageEvent which says:
When the setItem(), removeItem(), and clear() methods are called
on a Storage object x that is associated with a local storage area,
if the methods did something, then in every HTMLDocument object whose
Window object's localStorage attribute's Storage object is
associated with the same storage area, other than x, a
storage event must be fired, as described below.
(emphasis added).
I don't get anything on the error console or any alert. (Though it
works in Safari and Opera.)
Sounds like some bugs need to be filed on Safari and Opera.
-Boris
Re: StorageEvent.url (WAS: XMLHttpRequest.responseBlob)
On Thu, Apr 29, 2010 at 4:35 PM, Boris Zbarsky wrote:
> On 4/29/10 9:23 AM, Jeremy Orlow wrote:
>
>> Opera 10.50 does return false for your bit of javascript, but when I
>> enumerate the properties on event after causing a storage event, "url"
>> is there. Weird.
>>
>
> All that means is that the property is an own property of the object, not a
> property getter/setter pair on the prototype, no?
>
> It's interesting that you find this odd, given that this is exactly V8's
> behavior in general. Compare:
>
> alert("body" in HTMLDocument.prototype);
> alert("body" in document");
>
> in your favorite HTML page.
>
>
> My code did not work in Firefox 3.6.
>> https://developer.mozilla.org/en/DOM/Storage makes no mention of
>> StorageEvent. Do they actually support events?
>>
>
> Sure seem to, with "url" as the property name. Or at least there's
> definitely code in the tree to dispatch it when storage changes happen.
>
The following script does not work for me in 3.6. Would love to know what
I'm doing wrong:
window.onstorage = function() { alert("HI"); }
localStorage.foo = localStorage.foo + " ";
I don't get anything on the error console or any alert. (Though it works in
Safari and Opera.)
Re: StorageEvent.url (WAS: XMLHttpRequest.responseBlob)
On 4/29/10 9:23 AM, Jeremy Orlow wrote:
Opera 10.50 does return false for your bit of javascript, but when I
enumerate the properties on event after causing a storage event, "url"
is there. Weird.
All that means is that the property is an own property of the object,
not a property getter/setter pair on the prototype, no?
It's interesting that you find this odd, given that this is exactly V8's
behavior in general. Compare:
alert("body" in HTMLDocument.prototype);
alert("body" in document");
in your favorite HTML page.
My code did not work in Firefox 3.6.
https://developer.mozilla.org/en/DOM/Storage makes no mention of
StorageEvent. Do they actually support events?
Sure seem to, with "url" as the property name. Or at least there's
definitely code in the tree to dispatch it when storage changes happen.
-Boris
StorageEvent.url (WAS: XMLHttpRequest.responseBlob)
On Thu, Apr 29, 2010 at 6:11 AM, Simon Pieters wrote:
>
> You mean StorageEvent?
>
> javascript:alert('url' in StorageEvent.prototype)
>
> Opera: false
> Firefox: true
> Chrome: false
>
I tried actually causing a storage event and then enumerated its properties
with each browser and got somewhat different results. Chrome/Safari are as
you say. We call it "uri", but the last time it was changed was 2 years
ago, so I suspect this is just an artifact of an old version of the spec or
something.
Opera 10.50 does return false for your bit of javascript, but when I
enumerate the properties on event after causing a storage event, "url" is
there. Weird.
My code did not work in Firefox 3.6.
https://developer.mozilla.org/en/DOM/Storage makes no mention of
StorageEvent. Do they actually support events?
And IE also calls it a "url". (But they put onstorage on the document
instead of the window. And they have an onstoragecommit event as well. Did
this stuff ever come up on list??)
So, in conclusion, I suppose WebKit should change uri to url to match the
rest of the world?
J
Re: XMLHttpRequest.responseBlob
On Thu, 29 Apr 2010 05:27:44 +0200, Jonas Sicking wrote:
Can you change it back? We've implemented and written tests for
WebSocket.URL. WebKit has implemented EventSource.URL and
WebSocket.URL.
Do you plan to implement the File API attribute as .URL also?
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0803.html
I really think we should make sure we end up with a consistent naming
scheme here.
I agree.
If Gecko is the only engine that's going to do .url instead
of .URL, then I'm happy to change it back (on the assumption that Gecko
will eventually be forced to change to match). However, it would be a
pretty mess if we ended up developing APIs in the same year that had
different cases for the same attributes.
Out of curiosity, why does the year of the API matter?
Indeed. We should be consistent with document.URL also. :-)
The way I look at it is: if you tell 100 developers that there is a
property named 'url' on these objects (i.e. tell them, not show them
in writing), how many of them do you think will envision it written in
upper case characters, and how many will envision it in lower case
characters?
1) I think it depends on whether they are familiar with document.URL or
not.
2) I think most developers learn by reading tutorials or view source.
Does anyone implement EventStorage.url, by the way? I noticed that one
was
lowercase in the spec while I was doing the earlier change.
You mean StorageEvent?
javascript:alert('url' in StorageEvent.prototype)
Opera: false
Firefox: true
Chrome: false
--
Simon Pieters
Opera Software
Re: XMLHttpRequest.responseBlob
On Wed, Apr 28, 2010 at 8:18 PM, Ian Hickson wrote: > On Tue, 27 Apr 2010, Simon Pieters wrote: >> > >> > Fine, fine. I've updated HTML5 to rename WebSocket.URL, >> > EventSource.URL, and Stream.URL to be lowercase. >> >> Can you change it back? We've implemented and written tests for >> WebSocket.URL. WebKit has implemented EventSource.URL and WebSocket.URL. > > Do you plan to implement the File API attribute as .URL also? > > I really think we should make sure we end up with a consistent naming > scheme here. If Gecko is the only engine that's going to do .url instead > of .URL, then I'm happy to change it back (on the assumption that Gecko > will eventually be forced to change to match). However, it would be a > pretty mess if we ended up developing APIs in the same year that had > different cases for the same attributes. Out of curiosity, why does the year of the API matter? The way I look at it is: if you tell 100 developers that there is a property named 'url' on these objects (i.e. tell them, not show them in writing), how many of them do you think will envision it written in upper case characters, and how many will envision it in lower case characters? / Jonas
Re: XMLHttpRequest.responseBlob
On Tue, 27 Apr 2010, Simon Pieters wrote: > > > > Fine, fine. I've updated HTML5 to rename WebSocket.URL, > > EventSource.URL, and Stream.URL to be lowercase. > > Can you change it back? We've implemented and written tests for > WebSocket.URL. WebKit has implemented EventSource.URL and WebSocket.URL. Do you plan to implement the File API attribute as .URL also? I really think we should make sure we end up with a consistent naming scheme here. If Gecko is the only engine that's going to do .url instead of .URL, then I'm happy to change it back (on the assumption that Gecko will eventually be forced to change to match). However, it would be a pretty mess if we ended up developing APIs in the same year that had different cases for the same attributes. Does anyone implement EventStorage.url, by the way? I noticed that one was lowercase in the spec while I was doing the earlier change. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XMLHttpRequest.responseBlob
On Wed, Apr 28, 2010 at 12:45 PM, Darin Fisher wrote: > On Wed, Apr 28, 2010 at 11:57 AM, Michael Nordman > wrote: >> >> >> On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking wrote: >>> >>> Ugh, sent this originally to just Darin. Resending to the list. >>> >>> On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher >>> wrote: >>> > On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking >>> > wrote: >>> >> >>> >> On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher >>> >> wrote: >>> >> > On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking >>> >> > wrote: >>> >> >> >>> >> >> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher >>> >> >> wrote: >>> >> >> >> It would be nice to be able to allow streaming such that every >>> >> >> >> time >>> >> >> >> a >>> >> >> >> progress event is fired only the newly downloaded data is >>> >> >> >> available. >>> >> >> >> The UA is then free to throw away that data once the event is >>> >> >> >> done >>> >> >> >> firing. This would be useful in the cases when the page is able >>> >> >> >> to >>> >> >> >> do >>> >> >> >> incremental parsing of the resulting document. >>> >> >> >> >>> >> >> >> If we add a 'load mode' flag on XMLHttpRequest, which can't be >>> >> >> >> modified after send() is called, then streaming to a Blob could >>> >> >> >> simply >>> >> >> >> be another enum value for such a flag. >>> >> >> >> >>> >> >> >> There is still the problem of how the actual blob works. I.e. >>> >> >> >> does >>> >> >> >> .responseBlob return a new blob every time more data is >>> >> >> >> returned? Or >>> >> >> >> should the same Blob be constantly modifying? If modifying, what >>> >> >> >> happens to any in-progress reads when the file is modified? Or >>> >> >> >> do >>> >> >> >> you >>> >> >> >> just make the Blob available once the whole resource has been >>> >> >> >> downloaded? >>> >> >> >> >>> >> >> > >>> >> >> > >>> >> >> > This is why I suggested using FileWriter. FileWriter already has >>> >> >> > to >>> >> >> > deal with >>> >> >> > most of the problems you mentioned above, >>> >> >> >>> >> >> Actually, as far as I can tell FileWriter is write-only so it >>> >> >> doesn't >>> >> >> deal with any of the problems above. >>> >> > >>> >> > When you use createWriter, you are creating a FileWriter to an >>> >> > existing >>> >> > File. >>> >> > The user could attempt to create a FileReader to the very same File >>> >> > while >>> >> > a FileWriter is open to it. >>> >> > It is true that for there is no way to get at >>> >> > the >>> >> > underlying >>> >> > File object. That is perhaps a good thing for the use case of >>> >> > downloading >>> >> > to >>> >> > a location specified by the user. >>> >> >>> >> Ah. But as far as I can tell (and remember), it's still fairly >>> >> undefined what happens when the OS file under a File/Blob object is >>> >> mutated. >>> >> >>> >> / Jonas >>> > >>> > Agreed. I don't see it as a big problem. Do you? The application >>> > developer is >>> > in control. They get to specify the output file (via FileWriter) that >>> > XHR >>> > sends its >>> > output to, and they get to know when XHR is done writing. So, the >>> > application >>> > developer can avoid reading from the file until XHR is done writing. >>> >>> Well, it seems like a bigger deal here since the file is being >>> constantly modified as we're downloading data into it, no? So for >>> example if you grab a File object after the first progress event, what >>> does that File object contain after the second? Does it contain the >>> whole file, including the newly downloaded data? Or does it contain >>> only the data after the first progress event? Or is the File object >>> now invalid and can't be used? >> >> What gears did about that was to provide a 'snapshot' of the >> downloaded data each time responseBlob was called, with >> the 'snapshot' being consistent with the progress events >> having been seen by the caller. The 'snapshot' would remain >> valid until discarded by the caller. Each snapshot just provided >> a view onto the same data which maybe was in memory or >> maybe had spilled over to disk unbeknownst to the caller. >> >>> >>> I'm also still unsure that a FileWriter is what you want generally. If >>> you're just downloading temporary data, but data that happens to be so >>> large that you don't want to keep it in memory, you don't want to >>> bother the user asking for a location for that temporary file. Nor do >>> you want that file to be around once the user leaves the page. >> >> >> I think the point about not requiring the caller to manage the 'file' are >> important. >> >>> >>> Sure, if the use case is actually downloading and saving a file for >>> the user to use, rather than for the page to use, then a FileWriter >>> seems like it would work. I.e. if you want something like >>> "Content-Disposition: attachment", but where you can specify request >>> headers. Is that the use case? >> >> Mods to xhr to access the response more opaquely is a fairly general >> feature request. One specific
Re: XMLHttpRequest.responseBlob
On Wed, Apr 28, 2010 at 12:45 PM, Darin Fisher wrote: > On Wed, Apr 28, 2010 at 11:57 AM, Michael Nordman > wrote: >> On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking wrote: >>> >>> Ugh, sent this originally to just Darin. Resending to the list. >>> >>> On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher >>> wrote: >>> > On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking >>> > wrote: >>> >> >>> >> On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher >>> >> wrote: >>> >> > On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking >>> >> > wrote: >>> >> >> >>> >> >> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher >>> >> >> wrote: >>> >> >> >> It would be nice to be able to allow streaming such that every >>> >> >> >> time >>> >> >> >> a >>> >> >> >> progress event is fired only the newly downloaded data is >>> >> >> >> available. >>> >> >> >> The UA is then free to throw away that data once the event is >>> >> >> >> done >>> >> >> >> firing. This would be useful in the cases when the page is able >>> >> >> >> to >>> >> >> >> do >>> >> >> >> incremental parsing of the resulting document. >>> >> >> >> >>> >> >> >> If we add a 'load mode' flag on XMLHttpRequest, which can't be >>> >> >> >> modified after send() is called, then streaming to a Blob could >>> >> >> >> simply >>> >> >> >> be another enum value for such a flag. >>> >> >> >> >>> >> >> >> There is still the problem of how the actual blob works. I.e. >>> >> >> >> does >>> >> >> >> .responseBlob return a new blob every time more data is >>> >> >> >> returned? Or >>> >> >> >> should the same Blob be constantly modifying? If modifying, what >>> >> >> >> happens to any in-progress reads when the file is modified? Or >>> >> >> >> do >>> >> >> >> you >>> >> >> >> just make the Blob available once the whole resource has been >>> >> >> >> downloaded? >>> >> >> >> >>> >> >> > >>> >> >> > >>> >> >> > This is why I suggested using FileWriter. FileWriter already has >>> >> >> > to >>> >> >> > deal with >>> >> >> > most of the problems you mentioned above, >>> >> >> >>> >> >> Actually, as far as I can tell FileWriter is write-only so it >>> >> >> doesn't >>> >> >> deal with any of the problems above. >>> >> > >>> >> > When you use createWriter, you are creating a FileWriter to an >>> >> > existing >>> >> > File. >>> >> > The user could attempt to create a FileReader to the very same File >>> >> > while >>> >> > a FileWriter is open to it. >>> >> > It is true that for there is no way to get at >>> >> > the >>> >> > underlying >>> >> > File object. That is perhaps a good thing for the use case of >>> >> > downloading >>> >> > to >>> >> > a location specified by the user. >>> >> >>> >> Ah. But as far as I can tell (and remember), it's still fairly >>> >> undefined what happens when the OS file under a File/Blob object is >>> >> mutated. >>> >> >>> >> / Jonas >>> > >>> > Agreed. I don't see it as a big problem. Do you? The application >>> > developer is >>> > in control. They get to specify the output file (via FileWriter) that >>> > XHR >>> > sends its >>> > output to, and they get to know when XHR is done writing. So, the >>> > application >>> > developer can avoid reading from the file until XHR is done writing. >>> >>> Well, it seems like a bigger deal here since the file is being >>> constantly modified as we're downloading data into it, no? So for >>> example if you grab a File object after the first progress event, what >>> does that File object contain after the second? Does it contain the >>> whole file, including the newly downloaded data? Or does it contain >>> only the data after the first progress event? Or is the File object >>> now invalid and can't be used? >> >> What gears did about that was to provide a 'snapshot' of the >> downloaded data each time responseBlob was called, with >> the 'snapshot' being consistent with the progress events >> having been seen by the caller. The 'snapshot' would remain >> valid until discarded by the caller. Each snapshot just provided >> a view onto the same data which maybe was in memory or >> maybe had spilled over to disk unbeknownst to the caller. That sounds like a good solution. It does mean that if you want to read the whole file, you can't even *start* reading until the whole file has been downloaded. But that might be ok given that file reads should be relatively fast. I have always liked the idea of a Blob that's backed by a network request, but that's mostly convenience sugar over simply using XHR, so not terribly important. >>> Sure, if the use case is actually downloading and saving a file for >>> the user to use, rather than for the page to use, then a FileWriter >>> seems like it would work. I.e. if you want something like >>> "Content-Disposition: attachment", but where you can specify request >>> headers. Is that the use case? >> >> Mods to xhr to access the response more opaquely is a fairly general >> feature request. One specific use case is to download a resource via xhr >> and then save the results in a sand
Re: XMLHttpRequest.responseBlob
On Wed, Apr 28, 2010 at 11:57 AM, Michael Nordman wrote: > > > On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking wrote: > >> Ugh, sent this originally to just Darin. Resending to the list. >> >> On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher >> wrote: >> > On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking >> wrote: >> >> >> >> On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher >> wrote: >> >> > On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking >> wrote: >> >> >> >> >> >> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher >> >> >> wrote: >> >> >> >> It would be nice to be able to allow streaming such that every >> time >> >> >> >> a >> >> >> >> progress event is fired only the newly downloaded data is >> available. >> >> >> >> The UA is then free to throw away that data once the event is >> done >> >> >> >> firing. This would be useful in the cases when the page is able >> to >> >> >> >> do >> >> >> >> incremental parsing of the resulting document. >> >> >> >> >> >> >> >> If we add a 'load mode' flag on XMLHttpRequest, which can't be >> >> >> >> modified after send() is called, then streaming to a Blob could >> >> >> >> simply >> >> >> >> be another enum value for such a flag. >> >> >> >> >> >> >> >> There is still the problem of how the actual blob works. I.e. >> does >> >> >> >> .responseBlob return a new blob every time more data is returned? >> Or >> >> >> >> should the same Blob be constantly modifying? If modifying, what >> >> >> >> happens to any in-progress reads when the file is modified? Or do >> >> >> >> you >> >> >> >> just make the Blob available once the whole resource has been >> >> >> >> downloaded? >> >> >> >> >> >> >> > >> >> >> > >> >> >> > This is why I suggested using FileWriter. FileWriter already has >> to >> >> >> > deal with >> >> >> > most of the problems you mentioned above, >> >> >> >> >> >> Actually, as far as I can tell FileWriter is write-only so it >> doesn't >> >> >> deal with any of the problems above. >> >> > >> >> > When you use createWriter, you are creating a FileWriter to an >> existing >> >> > File. >> >> > The user could attempt to create a FileReader to the very same File >> >> > while >> >> > a FileWriter is open to it. >> >> > It is true that for there is no way to get at the >> >> > underlying >> >> > File object. That is perhaps a good thing for the use case of >> >> > downloading >> >> > to >> >> > a location specified by the user. >> >> >> >> Ah. But as far as I can tell (and remember), it's still fairly >> >> undefined what happens when the OS file under a File/Blob object is >> >> mutated. >> >> >> >> / Jonas >> > >> > Agreed. I don't see it as a big problem. Do you? The application >> > developer is >> > in control. They get to specify the output file (via FileWriter) that >> XHR >> > sends its >> > output to, and they get to know when XHR is done writing. So, the >> > application >> > developer can avoid reading from the file until XHR is done writing. >> >> Well, it seems like a bigger deal here since the file is being >> constantly modified as we're downloading data into it, no? So for >> example if you grab a File object after the first progress event, what >> does that File object contain after the second? Does it contain the >> whole file, including the newly downloaded data? Or does it contain >> only the data after the first progress event? Or is the File object >> now invalid and can't be used? >> > > What gears did about that was to provide a 'snapshot' of the > downloaded data each time responseBlob was called, with > the 'snapshot' being consistent with the progress events > having been seen by the caller. The 'snapshot' would remain > valid until discarded by the caller. Each snapshot just provided > a view onto the same data which maybe was in memory or > maybe had spilled over to disk unbeknownst to the caller. > > >> >> I'm also still unsure that a FileWriter is what you want generally. If >> you're just downloading temporary data, but data that happens to be so >> large that you don't want to keep it in memory, you don't want to >> bother the user asking for a location for that temporary file. Nor do >> you want that file to be around once the user leaves the page. >> > > I think the point about not requiring the caller to manage the 'file' are > important. > > >> Sure, if the use case is actually downloading and saving a file for >> the user to use, rather than for the page to use, then a FileWriter >> seems like it would work. I.e. if you want something like >> "Content-Disposition: attachment", but where you can specify request >> headers. Is that the use case? >> > > Mods to xhr to access the response more opaquely is a fairly general > feature request. One specific use case is to download a resource via xhr > and then save the results in a sandboxed file system. So "for the page to > use". > ^^^ That is the use case I'm primarily interested in. I think it would be beneficial if downloading to disk was not rate-limited by routing chunks
Re: XMLHttpRequest.responseBlob
On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking wrote: > Ugh, sent this originally to just Darin. Resending to the list. > > On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher wrote: > > On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking wrote: > >> > >> On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher > wrote: > >> > On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking > wrote: > >> >> > >> >> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher > >> >> wrote: > >> >> >> It would be nice to be able to allow streaming such that every > time > >> >> >> a > >> >> >> progress event is fired only the newly downloaded data is > available. > >> >> >> The UA is then free to throw away that data once the event is done > >> >> >> firing. This would be useful in the cases when the page is able to > >> >> >> do > >> >> >> incremental parsing of the resulting document. > >> >> >> > >> >> >> If we add a 'load mode' flag on XMLHttpRequest, which can't be > >> >> >> modified after send() is called, then streaming to a Blob could > >> >> >> simply > >> >> >> be another enum value for such a flag. > >> >> >> > >> >> >> There is still the problem of how the actual blob works. I.e. does > >> >> >> .responseBlob return a new blob every time more data is returned? > Or > >> >> >> should the same Blob be constantly modifying? If modifying, what > >> >> >> happens to any in-progress reads when the file is modified? Or do > >> >> >> you > >> >> >> just make the Blob available once the whole resource has been > >> >> >> downloaded? > >> >> >> > >> >> > > >> >> > > >> >> > This is why I suggested using FileWriter. FileWriter already has > to > >> >> > deal with > >> >> > most of the problems you mentioned above, > >> >> > >> >> Actually, as far as I can tell FileWriter is write-only so it doesn't > >> >> deal with any of the problems above. > >> > > >> > When you use createWriter, you are creating a FileWriter to an > existing > >> > File. > >> > The user could attempt to create a FileReader to the very same File > >> > while > >> > a FileWriter is open to it. > >> > It is true that for there is no way to get at the > >> > underlying > >> > File object. That is perhaps a good thing for the use case of > >> > downloading > >> > to > >> > a location specified by the user. > >> > >> Ah. But as far as I can tell (and remember), it's still fairly > >> undefined what happens when the OS file under a File/Blob object is > >> mutated. > >> > >> / Jonas > > > > Agreed. I don't see it as a big problem. Do you? The application > > developer is > > in control. They get to specify the output file (via FileWriter) that > XHR > > sends its > > output to, and they get to know when XHR is done writing. So, the > > application > > developer can avoid reading from the file until XHR is done writing. > > Well, it seems like a bigger deal here since the file is being > constantly modified as we're downloading data into it, no? So for > example if you grab a File object after the first progress event, what > does that File object contain after the second? Does it contain the > whole file, including the newly downloaded data? Or does it contain > only the data after the first progress event? Or is the File object > now invalid and can't be used? > What gears did about that was to provide a 'snapshot' of the downloaded data each time responseBlob was called, with the 'snapshot' being consistent with the progress events having been seen by the caller. The 'snapshot' would remain valid until discarded by the caller. Each snapshot just provided a view onto the same data which maybe was in memory or maybe had spilled over to disk unbeknownst to the caller. > > I'm also still unsure that a FileWriter is what you want generally. If > you're just downloading temporary data, but data that happens to be so > large that you don't want to keep it in memory, you don't want to > bother the user asking for a location for that temporary file. Nor do > you want that file to be around once the user leaves the page. > I think the point about not requiring the caller to manage the 'file' are important. > Sure, if the use case is actually downloading and saving a file for > the user to use, rather than for the page to use, then a FileWriter > seems like it would work. I.e. if you want something like > "Content-Disposition: attachment", but where you can specify request > headers. Is that the use case? > Mods to xhr to access the response more opaquely is a fairly general feature request. One specific use case is to download a resource via xhr and then save the results in a sandboxed file system. So "for the page to use". The notion of having a streaming interface on xhr is interesting. That with a BlobBuilder capability could work. If a streaming xhr mode provided new data in the form of 'blobs' where each blob was just the newly received data, the caller could use a BlobBuilder instance to concatenate the set of received data blobs. And then take blobBuilder.getBlob() and do
Re: XMLHttpRequest.responseBlob
Ugh, sent this originally to just Darin. Resending to the list. On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher wrote: > On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking wrote: >> >> On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher wrote: >> > On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking wrote: >> >> >> >> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher >> >> wrote: >> >> >> It would be nice to be able to allow streaming such that every time >> >> >> a >> >> >> progress event is fired only the newly downloaded data is available. >> >> >> The UA is then free to throw away that data once the event is done >> >> >> firing. This would be useful in the cases when the page is able to >> >> >> do >> >> >> incremental parsing of the resulting document. >> >> >> >> >> >> If we add a 'load mode' flag on XMLHttpRequest, which can't be >> >> >> modified after send() is called, then streaming to a Blob could >> >> >> simply >> >> >> be another enum value for such a flag. >> >> >> >> >> >> There is still the problem of how the actual blob works. I.e. does >> >> >> .responseBlob return a new blob every time more data is returned? Or >> >> >> should the same Blob be constantly modifying? If modifying, what >> >> >> happens to any in-progress reads when the file is modified? Or do >> >> >> you >> >> >> just make the Blob available once the whole resource has been >> >> >> downloaded? >> >> >> >> >> > >> >> > >> >> > This is why I suggested using FileWriter. FileWriter already has to >> >> > deal with >> >> > most of the problems you mentioned above, >> >> >> >> Actually, as far as I can tell FileWriter is write-only so it doesn't >> >> deal with any of the problems above. >> > >> > When you use createWriter, you are creating a FileWriter to an existing >> > File. >> > The user could attempt to create a FileReader to the very same File >> > while >> > a FileWriter is open to it. >> > It is true that for there is no way to get at the >> > underlying >> > File object. That is perhaps a good thing for the use case of >> > downloading >> > to >> > a location specified by the user. >> >> Ah. But as far as I can tell (and remember), it's still fairly >> undefined what happens when the OS file under a File/Blob object is >> mutated. >> >> / Jonas > > Agreed. I don't see it as a big problem. Do you? The application > developer is > in control. They get to specify the output file (via FileWriter) that XHR > sends its > output to, and they get to know when XHR is done writing. So, the > application > developer can avoid reading from the file until XHR is done writing. Well, it seems like a bigger deal here since the file is being constantly modified as we're downloading data into it, no? So for example if you grab a File object after the first progress event, what does that File object contain after the second? Does it contain the whole file, including the newly downloaded data? Or does it contain only the data after the first progress event? Or is the File object now invalid and can't be used? I'm also still unsure that a FileWriter is what you want generally. If you're just downloading temporary data, but data that happens to be so large that you don't want to keep it in memory, you don't want to bother the user asking for a location for that temporary file. Nor do you want that file to be around once the user leaves the page. Sure, if the use case is actually downloading and saving a file for the user to use, rather than for the page to use, then a FileWriter seems like it would work. I.e. if you want something like "Content-Disposition: attachment", but where you can specify request headers. Is that the use case? / Jonas
Re: XMLHttpRequest.responseBlob
On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking wrote: > On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher wrote: > > On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking wrote: > >> > >> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher > wrote: > >> >> It would be nice to be able to allow streaming such that every time a > >> >> progress event is fired only the newly downloaded data is available. > >> >> The UA is then free to throw away that data once the event is done > >> >> firing. This would be useful in the cases when the page is able to do > >> >> incremental parsing of the resulting document. > >> >> > >> >> If we add a 'load mode' flag on XMLHttpRequest, which can't be > >> >> modified after send() is called, then streaming to a Blob could > simply > >> >> be another enum value for such a flag. > >> >> > >> >> There is still the problem of how the actual blob works. I.e. does > >> >> .responseBlob return a new blob every time more data is returned? Or > >> >> should the same Blob be constantly modifying? If modifying, what > >> >> happens to any in-progress reads when the file is modified? Or do you > >> >> just make the Blob available once the whole resource has been > >> >> downloaded? > >> >> > >> > > >> > > >> > This is why I suggested using FileWriter. FileWriter already has to > >> > deal with > >> > most of the problems you mentioned above, > >> > >> Actually, as far as I can tell FileWriter is write-only so it doesn't > >> deal with any of the problems above. > > > > When you use createWriter, you are creating a FileWriter to an existing > > File. > > The user could attempt to create a FileReader to the very same File while > > a FileWriter is open to it. > > It is true that for there is no way to get at the > > underlying > > File object. That is perhaps a good thing for the use case of > downloading > > to > > a location specified by the user. > > Ah. But as far as I can tell (and remember), it's still fairly > undefined what happens when the OS file under a File/Blob object is > mutated. > > / Jonas > Agreed. I don't see it as a big problem. Do you? The application developer is in control. They get to specify the output file (via FileWriter) that XHR sends its output to, and they get to know when XHR is done writing. So, the application developer can avoid reading from the file until XHR is done writing. -Darin
Re: XMLHttpRequest.responseBlob
On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher wrote: > On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking wrote: >> >> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher wrote: >> >> It would be nice to be able to allow streaming such that every time a >> >> progress event is fired only the newly downloaded data is available. >> >> The UA is then free to throw away that data once the event is done >> >> firing. This would be useful in the cases when the page is able to do >> >> incremental parsing of the resulting document. >> >> >> >> If we add a 'load mode' flag on XMLHttpRequest, which can't be >> >> modified after send() is called, then streaming to a Blob could simply >> >> be another enum value for such a flag. >> >> >> >> There is still the problem of how the actual blob works. I.e. does >> >> .responseBlob return a new blob every time more data is returned? Or >> >> should the same Blob be constantly modifying? If modifying, what >> >> happens to any in-progress reads when the file is modified? Or do you >> >> just make the Blob available once the whole resource has been >> >> downloaded? >> >> >> > >> > >> > This is why I suggested using FileWriter. FileWriter already has to >> > deal with >> > most of the problems you mentioned above, >> >> Actually, as far as I can tell FileWriter is write-only so it doesn't >> deal with any of the problems above. > > When you use createWriter, you are creating a FileWriter to an existing > File. > The user could attempt to create a FileReader to the very same File while > a FileWriter is open to it. > It is true that for there is no way to get at the > underlying > File object. That is perhaps a good thing for the use case of downloading > to > a location specified by the user. Ah. But as far as I can tell (and remember), it's still fairly undefined what happens when the OS file under a File/Blob object is mutated. / Jonas
Re: XMLHttpRequest.responseBlob
On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking wrote:
> On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher wrote:
> >> It would be nice to be able to allow streaming such that every time a
> >> progress event is fired only the newly downloaded data is available.
> >> The UA is then free to throw away that data once the event is done
> >> firing. This would be useful in the cases when the page is able to do
> >> incremental parsing of the resulting document.
> >>
> >> If we add a 'load mode' flag on XMLHttpRequest, which can't be
> >> modified after send() is called, then streaming to a Blob could simply
> >> be another enum value for such a flag.
> >>
> >> There is still the problem of how the actual blob works. I.e. does
> >> .responseBlob return a new blob every time more data is returned? Or
> >> should the same Blob be constantly modifying? If modifying, what
> >> happens to any in-progress reads when the file is modified? Or do you
> >> just make the Blob available once the whole resource has been
> >> downloaded?
> >>
> >
> >
> > This is why I suggested using FileWriter. FileWriter already has to
> > deal with
> > most of the problems you mentioned above,
>
> Actually, as far as I can tell FileWriter is write-only so it doesn't
> deal with any of the problems above.
>
When you use createWriter, you are creating a FileWriter to an existing
File.
The user could attempt to create a FileReader to the very same File while
a FileWriter is open to it.
It is true that for there is no way to get at the
underlying
File object. That is perhaps a good thing for the use case of downloading
to
a location specified by the user.
>
> > and you can get a FileWriter
> > either from [1] or from a FileEntry object [2].
> > One possible API for engaging this mode might be:
> > var x = new XMLHttpRequest();
> > x.open("GET", url, true);
> > x.streamToFile(fileWriter);
> > x.send(null);
>
> And how would you get the actual data?
>
>
See above.
-Darin
Re: XMLHttpRequest.responseBlob
On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher wrote:
>> It would be nice to be able to allow streaming such that every time a
>> progress event is fired only the newly downloaded data is available.
>> The UA is then free to throw away that data once the event is done
>> firing. This would be useful in the cases when the page is able to do
>> incremental parsing of the resulting document.
>>
>> If we add a 'load mode' flag on XMLHttpRequest, which can't be
>> modified after send() is called, then streaming to a Blob could simply
>> be another enum value for such a flag.
>>
>> There is still the problem of how the actual blob works. I.e. does
>> .responseBlob return a new blob every time more data is returned? Or
>> should the same Blob be constantly modifying? If modifying, what
>> happens to any in-progress reads when the file is modified? Or do you
>> just make the Blob available once the whole resource has been
>> downloaded?
>>
>
>
> This is why I suggested using FileWriter. FileWriter already has to
> deal with
> most of the problems you mentioned above,
Actually, as far as I can tell FileWriter is write-only so it doesn't
deal with any of the problems above.
> and you can get a FileWriter
> either from [1] or from a FileEntry object [2].
> One possible API for engaging this mode might be:
> var x = new XMLHttpRequest();
> x.open("GET", url, true);
> x.streamToFile(fileWriter);
> x.send(null);
And how would you get the actual data?
/ Jonas
Re: XMLHttpRequest.responseBlob
On Tue, Apr 27, 2010 at 11:01 AM, Jonas Sicking wrote:
> On Mon, Apr 26, 2010 at 11:03 PM, Darin Fisher wrote:
> > On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking wrote:
> >>
> >> On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher
> wrote:
> >> > On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking
> wrote:
> >> >>
> >> >> On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher
> >> >> wrote:
> >> >> > There is some interest from application developers at Google in
> being
> >> >> > able
> >> >> > to get a Blob corresponding to the response body of a
> XMLHttpRequest.
> >> >> > The use case is to improve the efficiency of getting a Blob from a
> >> >> > binary
> >> >> > resource downloaded via XHR.
> >> >> > The alternative is to play games with character encodings so that
> >> >> > responseText can be used to fetch an image as a string, and then
> use
> >> >> > BlobBuilder to reconstruct the image file, again being careful with
> >> >> > the
> >> >> > implicit character conversions. All of this is very inefficient.
> >> >> > Is there any appetite for adding a responseBlob getter on XHR?
> >> >>
> >> >> There has been talk about exposing a responseBody property which
> would
> >> >> contain the binary response. However ECMAScript is still lacking a
> >> >> binary type.
> >> >>
> >> >> Blob does fit the bill in that it represents binary data, however
> it's
> >> >> asynchronous nature is probably not ideal here, right?
> >> >>
> >> >> / Jonas
> >> >
> >> >
> >> > I think there are applications that do not require direct access to
> the
> >> > response data.
> >> > For example,
> >> > 1- Download a binary resource (e.g., an image) via XHR.
> >> > 2- Load the resource using Blob.URN (assuming URN moves from File to
> >> > Blob).
> >> > It may be the case that providing direct access to the response data
> may
> >> > be
> >> > more
> >> > expensive than just providing the application with a handle to the
> data.
> >> > Consider
> >> > the case of large files.
> >>
> >> Ah, so you want the ability to have the XHR implementation stream to
> >> disk and then use a Blob to read from there? If so, you need more
> >> modifications as currently the XHR implementation is required to keep
> >> the whole response in memory anyway in order to be able to implement
> >> the .responseText property.
> >>
> >> So we'll need to add some way for the page to indicate to the
> >> implementation "I don't care about the .responseText or .responseXML
> >> properties, just responseBlob"
> >
> > I thought about this more, and I came to the same conclusion as you. I
> > agree that we wouldn't want to support .responseText or .responseXML if
> we
> > were streaming directly to a file because the implied synchronous
> readback
> > from disk would suck.
> > I'm not sure how to add such a feature to XHR in a way that is not
> awkward.
> > Perhaps if there was a way to bind a FileWriter to an XMLHttpRequest
> object
> > prior to calling send?
>
> Hmm.. what would that look like? Can you give an example of an API?
>
> I've been thinking for a while that we should add a 'streaming mode'
> for XHR anyway. Right now XHR is very inefficient when loading large
> amounts of data for two reasons. First of all the data needs to be
> appended to an existing buffer constantly, resulting in O(n^2)
> behavior. I.e. if you receive data in 1500 bytes packets, and download
> 1Mb of data, you end up first allocating 1500 bytes, then 3000, 4500,
> 6000, etc. All the way to the total file size. Second, as discussed
> here, you have to store the whole resulting file in memory.
>
A streaming mode would be excellent!
>
> It would be nice to be able to allow streaming such that every time a
> progress event is fired only the newly downloaded data is available.
> The UA is then free to throw away that data once the event is done
> firing. This would be useful in the cases when the page is able to do
> incremental parsing of the resulting document.
>
> If we add a 'load mode' flag on XMLHttpRequest, which can't be
> modified after send() is called, then streaming to a Blob could simply
> be another enum value for such a flag.
>
> There is still the problem of how the actual blob works. I.e. does
> .responseBlob return a new blob every time more data is returned? Or
> should the same Blob be constantly modifying? If modifying, what
> happens to any in-progress reads when the file is modified? Or do you
> just make the Blob available once the whole resource has been
> downloaded?
>
>
This is why I suggested using FileWriter. FileWriter already has to
deal with
most of the problems you mentioned above, and you can get a FileWriter
either from [1] or from a FileEntry object [2].
One possible API for engaging this mode might be:
var x = new XMLHttpRequest();
x.open("GET", url, true);
x.streamToFile(fileWriter);
x.send(null);
-Darin
[1]
http://dev.w3.org/2009/dap/file-system/file-writer.html#obtaining-file-writers-via-html-input-element
[2]
http://dev.w3.org/2009/dap/fil
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 11:03 PM, Darin Fisher wrote: > On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking wrote: >> >> On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher wrote: >> > On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking wrote: >> >> >> >> On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher >> >> wrote: >> >> > There is some interest from application developers at Google in being >> >> > able >> >> > to get a Blob corresponding to the response body of a XMLHttpRequest. >> >> > The use case is to improve the efficiency of getting a Blob from a >> >> > binary >> >> > resource downloaded via XHR. >> >> > The alternative is to play games with character encodings so that >> >> > responseText can be used to fetch an image as a string, and then use >> >> > BlobBuilder to reconstruct the image file, again being careful with >> >> > the >> >> > implicit character conversions. All of this is very inefficient. >> >> > Is there any appetite for adding a responseBlob getter on XHR? >> >> >> >> There has been talk about exposing a responseBody property which would >> >> contain the binary response. However ECMAScript is still lacking a >> >> binary type. >> >> >> >> Blob does fit the bill in that it represents binary data, however it's >> >> asynchronous nature is probably not ideal here, right? >> >> >> >> / Jonas >> > >> > >> > I think there are applications that do not require direct access to the >> > response data. >> > For example, >> > 1- Download a binary resource (e.g., an image) via XHR. >> > 2- Load the resource using Blob.URN (assuming URN moves from File to >> > Blob). >> > It may be the case that providing direct access to the response data may >> > be >> > more >> > expensive than just providing the application with a handle to the data. >> > Consider >> > the case of large files. >> >> Ah, so you want the ability to have the XHR implementation stream to >> disk and then use a Blob to read from there? If so, you need more >> modifications as currently the XHR implementation is required to keep >> the whole response in memory anyway in order to be able to implement >> the .responseText property. >> >> So we'll need to add some way for the page to indicate to the >> implementation "I don't care about the .responseText or .responseXML >> properties, just responseBlob" > > I thought about this more, and I came to the same conclusion as you. I > agree that we wouldn't want to support .responseText or .responseXML if we > were streaming directly to a file because the implied synchronous readback > from disk would suck. > I'm not sure how to add such a feature to XHR in a way that is not awkward. > Perhaps if there was a way to bind a FileWriter to an XMLHttpRequest object > prior to calling send? Hmm.. what would that look like? Can you give an example of an API? I've been thinking for a while that we should add a 'streaming mode' for XHR anyway. Right now XHR is very inefficient when loading large amounts of data for two reasons. First of all the data needs to be appended to an existing buffer constantly, resulting in O(n^2) behavior. I.e. if you receive data in 1500 bytes packets, and download 1Mb of data, you end up first allocating 1500 bytes, then 3000, 4500, 6000, etc. All the way to the total file size. Second, as discussed here, you have to store the whole resulting file in memory. It would be nice to be able to allow streaming such that every time a progress event is fired only the newly downloaded data is available. The UA is then free to throw away that data once the event is done firing. This would be useful in the cases when the page is able to do incremental parsing of the resulting document. If we add a 'load mode' flag on XMLHttpRequest, which can't be modified after send() is called, then streaming to a Blob could simply be another enum value for such a flag. There is still the problem of how the actual blob works. I.e. does .responseBlob return a new blob every time more data is returned? Or should the same Blob be constantly modifying? If modifying, what happens to any in-progress reads when the file is modified? Or do you just make the Blob available once the whole resource has been downloaded? / Jonas
Re: XMLHttpRequest.responseBlob
On Tue, Apr 27, 2010 at 10:11 AM, Eric Uhrhane wrote: > On Mon, Apr 26, 2010 at 11:03 PM, Darin Fisher wrote: > > On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking wrote: > >> > >> On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher > wrote: > >> > On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking > wrote: > >> >> > >> >> On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher > >> >> wrote: > >> >> > There is some interest from application developers at Google in > being > >> >> > able > >> >> > to get a Blob corresponding to the response body of a > XMLHttpRequest. > >> >> > The use case is to improve the efficiency of getting a Blob from a > >> >> > binary > >> >> > resource downloaded via XHR. > >> >> > The alternative is to play games with character encodings so that > >> >> > responseText can be used to fetch an image as a string, and then > use > >> >> > BlobBuilder to reconstruct the image file, again being careful with > >> >> > the > >> >> > implicit character conversions. All of this is very inefficient. > >> >> > Is there any appetite for adding a responseBlob getter on XHR? > >> >> > >> >> There has been talk about exposing a responseBody property which > would > >> >> contain the binary response. However ECMAScript is still lacking a > >> >> binary type. > >> >> > >> >> Blob does fit the bill in that it represents binary data, however > it's > >> >> asynchronous nature is probably not ideal here, right? > >> >> > >> >> / Jonas > >> > > >> > > >> > I think there are applications that do not require direct access to > the > >> > response data. > >> > For example, > >> > 1- Download a binary resource (e.g., an image) via XHR. > >> > 2- Load the resource using Blob.URN (assuming URN moves from File to > >> > Blob). > >> > It may be the case that providing direct access to the response data > may > >> > be > >> > more > >> > expensive than just providing the application with a handle to the > data. > >> > Consider > >> > the case of large files. > >> > >> Ah, so you want the ability to have the XHR implementation stream to > >> disk and then use a Blob to read from there? If so, you need more > >> modifications as currently the XHR implementation is required to keep > >> the whole response in memory anyway in order to be able to implement > >> the .responseText property. > >> > >> So we'll need to add some way for the page to indicate to the > >> implementation "I don't care about the .responseText or .responseXML > >> properties, just responseBlob" > >> > >> / Jonas > > > > > > I thought about this more, and I came to the same conclusion as you. I > > agree that we wouldn't want to support .responseText or .responseXML if > we > > were streaming directly to a file because the implied synchronous > readback > > from disk would suck. > > I'm not sure how to add such a feature to XHR in a way that is not > awkward. > > Perhaps if there was a way to bind a FileWriter to an XMLHttpRequest > object > > prior to calling send? > > A FileWriter is quite a bit more limited than a File/Blob. You can't > slice it, for instance, and you can't write it to multiple files > without writing, reading back, and writing again. > > All true, but my suggestion was based on the notion that XHR would be writing to a disk location in order to provide a Blob to that location. So, it might make sense to allow the application to specify the underlying file location. That seems to be what FileWriter can be used for. The application would presumably have access to the File that the FileWriter modifies. This could be useful in conjunction with to download a file from the cloud to a location of the user's choice without requiring any intermediate copy of the entire file. -Darin
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 11:03 PM, Darin Fisher wrote: > On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking wrote: >> >> On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher wrote: >> > On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking wrote: >> >> >> >> On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher >> >> wrote: >> >> > There is some interest from application developers at Google in being >> >> > able >> >> > to get a Blob corresponding to the response body of a XMLHttpRequest. >> >> > The use case is to improve the efficiency of getting a Blob from a >> >> > binary >> >> > resource downloaded via XHR. >> >> > The alternative is to play games with character encodings so that >> >> > responseText can be used to fetch an image as a string, and then use >> >> > BlobBuilder to reconstruct the image file, again being careful with >> >> > the >> >> > implicit character conversions. All of this is very inefficient. >> >> > Is there any appetite for adding a responseBlob getter on XHR? >> >> >> >> There has been talk about exposing a responseBody property which would >> >> contain the binary response. However ECMAScript is still lacking a >> >> binary type. >> >> >> >> Blob does fit the bill in that it represents binary data, however it's >> >> asynchronous nature is probably not ideal here, right? >> >> >> >> / Jonas >> > >> > >> > I think there are applications that do not require direct access to the >> > response data. >> > For example, >> > 1- Download a binary resource (e.g., an image) via XHR. >> > 2- Load the resource using Blob.URN (assuming URN moves from File to >> > Blob). >> > It may be the case that providing direct access to the response data may >> > be >> > more >> > expensive than just providing the application with a handle to the data. >> > Consider >> > the case of large files. >> >> Ah, so you want the ability to have the XHR implementation stream to >> disk and then use a Blob to read from there? If so, you need more >> modifications as currently the XHR implementation is required to keep >> the whole response in memory anyway in order to be able to implement >> the .responseText property. >> >> So we'll need to add some way for the page to indicate to the >> implementation "I don't care about the .responseText or .responseXML >> properties, just responseBlob" >> >> / Jonas > > > I thought about this more, and I came to the same conclusion as you. I > agree that we wouldn't want to support .responseText or .responseXML if we > were streaming directly to a file because the implied synchronous readback > from disk would suck. > I'm not sure how to add such a feature to XHR in a way that is not awkward. > Perhaps if there was a way to bind a FileWriter to an XMLHttpRequest object > prior to calling send? A FileWriter is quite a bit more limited than a File/Blob. You can't slice it, for instance, and you can't write it to multiple files without writing, reading back, and writing again.
Re: XMLHttpRequest.responseBlob
On Tue, 27 Apr 2010 10:00:02 +0200, Jonas Sicking wrote: On Tue, Apr 27, 2010 at 12:12 AM, Simon Pieters wrote: I would rather keep consistency with the hundreds of other properties that use lower case name, than the single one that use upper case. I would rather have all attributes with the same name use the same case. Add to that the fact that Document.URL is fairly rarely used. It's more used than referrer, lastModified, charset, characterSet, defaultCharset, dir, head, embeds, plugins, links, scripts, innerHTML, activeElement, designMode and commands on HTMLDocument according to google code search. Why restrict yourself to the HTMLDocument interface? Because I don't have time to research the whole Web platform, and I don't need to to make my point that document.URL isn't so rarely used as claimed. There are literally hundreds of properties in the DOM. Every single one uses a camelCase naming scheme for properties. Names starting with upper case is only used for "interface" names. Same thing with all javascript libraries that I can think of off the top of my head. And same thing with all built in properties defined in EMCAScript. The only exception that the web depends on is Document.URL. I don't think we can give a property an all uppercase name and claim that we're following any sort of established pattern. Sure. I agree it doesn't follow the pattern. I still would rather have all attributes with the same name use the same case, since it's easier to remember as an author. -- Simon Pieters Opera Software
Re: XMLHttpRequest.responseBlob
On Tue, Apr 27, 2010 at 12:12 AM, Simon Pieters wrote: >>> I would rather keep consistency with the hundreds of other properties >>> that use lower case name, than the single one that use upper case. > > I would rather have all attributes with the same name use the same case. > > >>> Add >>> to that the fact that Document.URL is fairly rarely used. > > It's more used than referrer, lastModified, charset, characterSet, > defaultCharset, dir, head, embeds, plugins, links, scripts, innerHTML, > activeElement, designMode and commands on HTMLDocument according to google > code search. Why restrict yourself to the HTMLDocument interface? There are literally hundreds of properties in the DOM. Every single one uses a camelCase naming scheme for properties. Names starting with upper case is only used for "interface" names. Same thing with all javascript libraries that I can think of off the top of my head. And same thing with all built in properties defined in EMCAScript. The only exception that the web depends on is Document.URL. I don't think we can give a property an all uppercase name and claim that we're following any sort of established pattern. / Jonas
Re: XMLHttpRequest.responseBlob
On Tue, 27 Apr 2010 01:19:52 +0200, Ian Hickson wrote: On Mon, 26 Apr 2010, Jonas Sicking wrote: I initially implemented an uppercased name, but when I was writing test cases for this property it was incredibly awkward to use the uppercased version and I kept mistyping it using the lower cased name. I've had no problem writing tests with the uppercase name. I would rather keep consistency with the hundreds of other properties that use lower case name, than the single one that use upper case. I would rather have all attributes with the same name use the same case. Add to that the fact that Document.URL is fairly rarely used. It's more used than referrer, lastModified, charset, characterSet, defaultCharset, dir, head, embeds, plugins, links, scripts, innerHTML, activeElement, designMode and commands on HTMLDocument according to google code search. Fine, fine. I've updated HTML5 to rename WebSocket.URL, EventSource.URL, and Stream.URL to be lowercase. Can you change it back? We've implemented and written tests for WebSocket.URL. WebKit has implemented EventSource.URL and WebSocket.URL. -- Simon Pieters Opera Software
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking wrote: > On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher wrote: > > On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking wrote: > >> > >> On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher > wrote: > >> > There is some interest from application developers at Google in being > >> > able > >> > to get a Blob corresponding to the response body of a XMLHttpRequest. > >> > The use case is to improve the efficiency of getting a Blob from a > >> > binary > >> > resource downloaded via XHR. > >> > The alternative is to play games with character encodings so that > >> > responseText can be used to fetch an image as a string, and then use > >> > BlobBuilder to reconstruct the image file, again being careful with > the > >> > implicit character conversions. All of this is very inefficient. > >> > Is there any appetite for adding a responseBlob getter on XHR? > >> > >> There has been talk about exposing a responseBody property which would > >> contain the binary response. However ECMAScript is still lacking a > >> binary type. > >> > >> Blob does fit the bill in that it represents binary data, however it's > >> asynchronous nature is probably not ideal here, right? > >> > >> / Jonas > > > > > > I think there are applications that do not require direct access to the > > response data. > > For example, > > 1- Download a binary resource (e.g., an image) via XHR. > > 2- Load the resource using Blob.URN (assuming URN moves from File to > Blob). > > It may be the case that providing direct access to the response data may > be > > more > > expensive than just providing the application with a handle to the data. > > Consider > > the case of large files. > > Ah, so you want the ability to have the XHR implementation stream to > disk and then use a Blob to read from there? If so, you need more > modifications as currently the XHR implementation is required to keep > the whole response in memory anyway in order to be able to implement > the .responseText property. > > So we'll need to add some way for the page to indicate to the > implementation "I don't care about the .responseText or .responseXML > properties, just responseBlob" > > / Jonas > I thought about this more, and I came to the same conclusion as you. I agree that we wouldn't want to support .responseText or .responseXML if we were streaming directly to a file because the implied synchronous readback from disk would suck. I'm not sure how to add such a feature to XHR in a way that is not awkward. Perhaps if there was a way to bind a FileWriter to an XMLHttpRequest object prior to calling send? -Darin
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 5:22 PM, Michael Nordman wrote: > > > On Mon, Apr 26, 2010 at 4:24 PM, Jonas Sicking wrote: >> >> On Mon, Apr 26, 2010 at 4:19 PM, Thomas Broyer wrote: >> > On Tue, Apr 27, 2010 at 1:11 AM, Jonas Sicking wrote: >> >> >> >> I'm not sure I understand how you envision the implementation working. >> >> You can't before hand know that the implementation won't ever access >> >> those properties (at least not without solving the halting problem). >> >> So you'll have to keep all the data in memory, just in case >> >> .reponseText is accessed. >> > >> > Couldn't you stream to disk, and in case responseText or responseXML >> > is called then read back from disk? You'd then have to "keep all the >> > data in memory" only when .responseText is used. >> >> That requires synchronous IO, something we're trying hard to avoid. >> Apple has said in the past that they are not willing to implement APIs >> that require synchronous IO. And in Firefox we're working on removing >> all places where it's used. Both in the implementation of various >> features exposed to web pages, but also in the product itself. > > (geez halting problem) > Spill over to disk as a response gets "too big", a function of memory > available on the device. If a response gets "too big" its possibly being > swapped in VM anyway. You may know if its "too big" from the get go based on > content-length headers. > So if responseText is accessed on "too big" of a resource, yes that may > involve explicit file system IO (big deal). There's a trade off here... > cleaner API vs quirky API to make life easier for the user-agent. I was > leaning towards cleaner API. It does mean though that a UA which doesn't want to use synchronous IO will have to keep all the data in memory, and thus not fulfill what I understood to be Darin's requirement. As far as I know that means at least firefox and safari. Don't know how the other browsers feel about it. / Jonas
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 4:24 PM, Jonas Sicking wrote: > On Mon, Apr 26, 2010 at 4:19 PM, Thomas Broyer wrote: > > On Tue, Apr 27, 2010 at 1:11 AM, Jonas Sicking wrote: > >> > >> I'm not sure I understand how you envision the implementation working. > >> You can't before hand know that the implementation won't ever access > >> those properties (at least not without solving the halting problem). > >> So you'll have to keep all the data in memory, just in case > >> .reponseText is accessed. > > > > Couldn't you stream to disk, and in case responseText or responseXML > > is called then read back from disk? You'd then have to "keep all the > > data in memory" only when .responseText is used. > > That requires synchronous IO, something we're trying hard to avoid. > Apple has said in the past that they are not willing to implement APIs > that require synchronous IO. And in Firefox we're working on removing > all places where it's used. Both in the implementation of various > features exposed to web pages, but also in the product itself. > (geez halting problem) Spill over to disk as a response gets "too big", a function of memory available on the device. If a response gets "too big" its possibly being swapped in VM anyway. You may know if its "too big" from the get go based on content-length headers. So if responseText is accessed on "too big" of a resource, yes that may involve explicit file system IO (big deal). There's a trade off here... cleaner API vs quirky API to make life easier for the user-agent. I was leaning towards cleaner API. > / Jonas >
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 4:19 PM, Thomas Broyer wrote: > On Tue, Apr 27, 2010 at 1:11 AM, Jonas Sicking wrote: >> >> I'm not sure I understand how you envision the implementation working. >> You can't before hand know that the implementation won't ever access >> those properties (at least not without solving the halting problem). >> So you'll have to keep all the data in memory, just in case >> .reponseText is accessed. > > Couldn't you stream to disk, and in case responseText or responseXML > is called then read back from disk? You'd then have to "keep all the > data in memory" only when .responseText is used. That requires synchronous IO, something we're trying hard to avoid. Apple has said in the past that they are not willing to implement APIs that require synchronous IO. And in Firefox we're working on removing all places where it's used. Both in the implementation of various features exposed to web pages, but also in the product itself. / Jonas
Re: XMLHttpRequest.responseBlob
On Tue, Apr 27, 2010 at 1:11 AM, Jonas Sicking wrote: > > I'm not sure I understand how you envision the implementation working. > You can't before hand know that the implementation won't ever access > those properties (at least not without solving the halting problem). > So you'll have to keep all the data in memory, just in case > .reponseText is accessed. Couldn't you stream to disk, and in case responseText or responseXML is called then read back from disk? You'd then have to "keep all the data in memory" only when .responseText is used. -- Thomas Broyer /tɔ.ma.bʁwa.je/
Re: XMLHttpRequest.responseBlob
On Mon, 26 Apr 2010, Jonas Sicking wrote: > > I initially implemented an uppercased name, but when I was writing test > cases for this property it was incredibly awkward to use the uppercased > version and I kept mistyping it using the lower cased name. > > I would rather keep consistency with the hundreds of other properties > that use lower case name, than the single one that use upper case. Add > to that the fact that Document.URL is fairly rarely used. Fine, fine. I've updated HTML5 to rename WebSocket.URL, EventSource.URL, and Stream.URL to be lowercase. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 4:01 PM, Michael Nordman wrote: > > > On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking wrote: >> >> On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher wrote: >> > On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking wrote: >> >> >> >> On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher >> >> wrote: >> >> > There is some interest from application developers at Google in being >> >> > able >> >> > to get a Blob corresponding to the response body of a XMLHttpRequest. >> >> > The use case is to improve the efficiency of getting a Blob from a >> >> > binary >> >> > resource downloaded via XHR. >> >> > The alternative is to play games with character encodings so that >> >> > responseText can be used to fetch an image as a string, and then use >> >> > BlobBuilder to reconstruct the image file, again being careful with >> >> > the >> >> > implicit character conversions. All of this is very inefficient. >> >> > Is there any appetite for adding a responseBlob getter on XHR? >> >> >> >> There has been talk about exposing a responseBody property which would >> >> contain the binary response. However ECMAScript is still lacking a >> >> binary type. >> >> >> >> Blob does fit the bill in that it represents binary data, however it's >> >> asynchronous nature is probably not ideal here, right? >> >> >> >> / Jonas >> > >> > >> > I think there are applications that do not require direct access to the >> > response data. >> > For example, >> > 1- Download a binary resource (e.g., an image) via XHR. >> > 2- Load the resource using Blob.URN (assuming URN moves from File to >> > Blob). >> > It may be the case that providing direct access to the response data may >> > be >> > more >> > expensive than just providing the application with a handle to the data. >> > Consider >> > the case of large files. >> >> Ah, so you want the ability to have the XHR implementation stream to >> disk and then use a Blob to read from there? If so, you need more >> modifications as currently the XHR implementation is required to keep >> the whole response in memory anyway in order to be able to implement >> the .responseText property. >> >> So we'll need to add some way for the page to indicate to the >> implementation "I don't care about the .responseText or .responseXML >> properties, just responseBlob" > > Not sure we need additional API for that. If the page doesn't access those > properties, its indicating that it doesn't need them. I'm not sure I understand how you envision the implementation working. You can't before hand know that the implementation won't ever access those properties (at least not without solving the halting problem). So you'll have to keep all the data in memory, just in case .reponseText is accessed. / Jonas
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 4:02 PM, James Robinson wrote: > On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking wrote: >> >> On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher wrote: >> > On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking wrote: >> >> >> >> On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher >> >> wrote: >> >> > There is some interest from application developers at Google in being >> >> > able >> >> > to get a Blob corresponding to the response body of a XMLHttpRequest. >> >> > The use case is to improve the efficiency of getting a Blob from a >> >> > binary >> >> > resource downloaded via XHR. >> >> > The alternative is to play games with character encodings so that >> >> > responseText can be used to fetch an image as a string, and then use >> >> > BlobBuilder to reconstruct the image file, again being careful with >> >> > the >> >> > implicit character conversions. All of this is very inefficient. >> >> > Is there any appetite for adding a responseBlob getter on XHR? >> >> >> >> There has been talk about exposing a responseBody property which would >> >> contain the binary response. However ECMAScript is still lacking a >> >> binary type. >> >> >> >> Blob does fit the bill in that it represents binary data, however it's >> >> asynchronous nature is probably not ideal here, right? >> >> >> >> / Jonas >> > >> > >> > I think there are applications that do not require direct access to the >> > response data. >> > For example, >> > 1- Download a binary resource (e.g., an image) via XHR. >> > 2- Load the resource using Blob.URN (assuming URN moves from File to >> > Blob). >> > It may be the case that providing direct access to the response data may >> > be >> > more >> > expensive than just providing the application with a handle to the data. >> > Consider >> > the case of large files. >> >> Ah, so you want the ability to have the XHR implementation stream to >> disk and then use a Blob to read from there? If so, you need more >> modifications as currently the XHR implementation is required to keep >> the whole response in memory anyway in order to be able to implement >> the .responseText property. > > The user agent still has to keep the whole response around. The advantage > of being able to refer to the response body as an opaque handle is that the > user agent does not have to re-encode the entire response body just so > javascript can pass the response back to some other system that wants the > original binary data. Darins requested use case was large enough data sets that he didn't want to keep them in memory, as I understood it. So the expensive part isn't encoding to the desired charset, but simply keeping megabytes of data in memory. / Jonas
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 3:57 PM, Ian Hickson wrote: > On Mon, 26 Apr 2010, Jonas Sicking wrote: >> > >> > Can we please rename .URN to .URL for consistency with the rest of the >> > platform? It really sticks out like a sore thumb being the only one >> > that's different... I'm worried people are going to implement it as is >> > if we don't update the spec soon. >> >> For what it's worth, I've implemented it as .url in Firefox. > > Any chance we can get that changed to uppercase for consistency with > Document.URL? I agree that uppercase is not common in the APIs, but I'd > rather we keep the platform consistent when it comes to attributes with > the same name rather than have the APIs depend on the prevailing wisdom at > the time when they were invented... We've had this discussion before :) I initially implemented an uppercased name, but when I was writing test cases for this property it was incredibly awkward to use the uppercased version and I kept mistyping it using the lower cased name. I would rather keep consistency with the hundreds of other properties that use lower case name, than the single one that use upper case. Add to that the fact that Document.URL is fairly rarely used. / Jonas
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking wrote: > On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher wrote: > > On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking wrote: > >> > >> On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher > wrote: > >> > There is some interest from application developers at Google in being > >> > able > >> > to get a Blob corresponding to the response body of a XMLHttpRequest. > >> > The use case is to improve the efficiency of getting a Blob from a > >> > binary > >> > resource downloaded via XHR. > >> > The alternative is to play games with character encodings so that > >> > responseText can be used to fetch an image as a string, and then use > >> > BlobBuilder to reconstruct the image file, again being careful with > the > >> > implicit character conversions. All of this is very inefficient. > >> > Is there any appetite for adding a responseBlob getter on XHR? > >> > >> There has been talk about exposing a responseBody property which would > >> contain the binary response. However ECMAScript is still lacking a > >> binary type. > >> > >> Blob does fit the bill in that it represents binary data, however it's > >> asynchronous nature is probably not ideal here, right? > >> > >> / Jonas > > > > > > I think there are applications that do not require direct access to the > > response data. > > For example, > > 1- Download a binary resource (e.g., an image) via XHR. > > 2- Load the resource using Blob.URN (assuming URN moves from File to > Blob). > > It may be the case that providing direct access to the response data may > be > > more > > expensive than just providing the application with a handle to the data. > > Consider > > the case of large files. > > Ah, so you want the ability to have the XHR implementation stream to > disk and then use a Blob to read from there? If so, you need more > modifications as currently the XHR implementation is required to keep > the whole response in memory anyway in order to be able to implement > the .responseText property. > The user agent still has to keep the whole response around. The advantage of being able to refer to the response body as an opaque handle is that the user agent does not have to re-encode the entire response body just so javascript can pass the response back to some other system that wants the original binary data. > > So we'll need to add some way for the page to indicate to the > implementation "I don't care about the .responseText or .responseXML > properties, just responseBlob" That's simple, the page doesn't touch .responseText or .responseXML on the XMLHttpRequest object. If they do, then the user agent will have to re-encode the string (if needed) and make them available to script. - James > > / Jonas > >
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking wrote: > On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher wrote: > > On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking wrote: > >> > >> On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher > wrote: > >> > There is some interest from application developers at Google in being > >> > able > >> > to get a Blob corresponding to the response body of a XMLHttpRequest. > >> > The use case is to improve the efficiency of getting a Blob from a > >> > binary > >> > resource downloaded via XHR. > >> > The alternative is to play games with character encodings so that > >> > responseText can be used to fetch an image as a string, and then use > >> > BlobBuilder to reconstruct the image file, again being careful with > the > >> > implicit character conversions. All of this is very inefficient. > >> > Is there any appetite for adding a responseBlob getter on XHR? > >> > >> There has been talk about exposing a responseBody property which would > >> contain the binary response. However ECMAScript is still lacking a > >> binary type. > >> > >> Blob does fit the bill in that it represents binary data, however it's > >> asynchronous nature is probably not ideal here, right? > >> > >> / Jonas > > > > > > I think there are applications that do not require direct access to the > > response data. > > For example, > > 1- Download a binary resource (e.g., an image) via XHR. > > 2- Load the resource using Blob.URN (assuming URN moves from File to > Blob). > > It may be the case that providing direct access to the response data may > be > > more > > expensive than just providing the application with a handle to the data. > > Consider > > the case of large files. > > Ah, so you want the ability to have the XHR implementation stream to > disk and then use a Blob to read from there? If so, you need more > modifications as currently the XHR implementation is required to keep > the whole response in memory anyway in order to be able to implement > the .responseText property. > > So we'll need to add some way for the page to indicate to the > implementation "I don't care about the .responseText or .responseXML > properties, just responseBlob" > Not sure we need additional API for that. If the page doesn't access those properties, its indicating that it doesn't need them. > > / Jonas > >
Re: XMLHttpRequest.responseBlob
On Mon, 26 Apr 2010, Jonas Sicking wrote: > > > > Can we please rename .URN to .URL for consistency with the rest of the > > platform? It really sticks out like a sore thumb being the only one > > that's different... I'm worried people are going to implement it as is > > if we don't update the spec soon. > > For what it's worth, I've implemented it as .url in Firefox. Any chance we can get that changed to uppercase for consistency with Document.URL? I agree that uppercase is not common in the APIs, but I'd rather we keep the platform consistent when it comes to attributes with the same name rather than have the APIs depend on the prevailing wisdom at the time when they were invented... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher wrote: > On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking wrote: >> >> On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher wrote: >> > There is some interest from application developers at Google in being >> > able >> > to get a Blob corresponding to the response body of a XMLHttpRequest. >> > The use case is to improve the efficiency of getting a Blob from a >> > binary >> > resource downloaded via XHR. >> > The alternative is to play games with character encodings so that >> > responseText can be used to fetch an image as a string, and then use >> > BlobBuilder to reconstruct the image file, again being careful with the >> > implicit character conversions. All of this is very inefficient. >> > Is there any appetite for adding a responseBlob getter on XHR? >> >> There has been talk about exposing a responseBody property which would >> contain the binary response. However ECMAScript is still lacking a >> binary type. >> >> Blob does fit the bill in that it represents binary data, however it's >> asynchronous nature is probably not ideal here, right? >> >> / Jonas > > > I think there are applications that do not require direct access to the > response data. > For example, > 1- Download a binary resource (e.g., an image) via XHR. > 2- Load the resource using Blob.URN (assuming URN moves from File to Blob). > It may be the case that providing direct access to the response data may be > more > expensive than just providing the application with a handle to the data. > Consider > the case of large files. Ah, so you want the ability to have the XHR implementation stream to disk and then use a Blob to read from there? If so, you need more modifications as currently the XHR implementation is required to keep the whole response in memory anyway in order to be able to implement the .responseText property. So we'll need to add some way for the page to indicate to the implementation "I don't care about the .responseText or .responseXML properties, just responseBlob" / Jonas
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 3:43 PM, Ian Hickson wrote: > On Mon, 26 Apr 2010, Darin Fisher wrote: >> >> 2- Load the resource using Blob.URN (assuming URN moves from File to >> Blob). > > Can we please rename .URN to .URL for consistency with the rest of the > platform? It really sticks out like a sore thumb being the only one that's > different... I'm worried people are going to implement it as is if we > don't update the spec soon. For what it's worth, I've implemented it as .url in Firefox. / Jonas
Re: XMLHttpRequest.responseBlob
On Mon, 26 Apr 2010, Darin Fisher wrote: > > 2- Load the resource using Blob.URN (assuming URN moves from File to > Blob). Can we please rename .URN to .URL for consistency with the rest of the platform? It really sticks out like a sore thumb being the only one that's different... I'm worried people are going to implement it as is if we don't update the spec soon. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking wrote: > On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher wrote: > > There is some interest from application developers at Google in being > able > > to get a Blob corresponding to the response body of a XMLHttpRequest. > > The use case is to improve the efficiency of getting a Blob from a binary > > resource downloaded via XHR. > > The alternative is to play games with character encodings so that > > responseText can be used to fetch an image as a string, and then use > > BlobBuilder to reconstruct the image file, again being careful with the > > implicit character conversions. All of this is very inefficient. > > Is there any appetite for adding a responseBlob getter on XHR? > > There has been talk about exposing a responseBody property which would > contain the binary response. However ECMAScript is still lacking a > binary type. > > Blob does fit the bill in that it represents binary data, however it's > asynchronous nature is probably not ideal here, right? > > / Jonas > I think there are applications that do not require direct access to the response data. For example, 1- Download a binary resource (e.g., an image) via XHR. 2- Load the resource using Blob.URN (assuming URN moves from File to Blob). It may be the case that providing direct access to the response data may be more expensive than just providing the application with a handle to the data. Consider the case of large files. -Darin
Re: XMLHttpRequest.responseBlob
On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher wrote: > There is some interest from application developers at Google in being able > to get a Blob corresponding to the response body of a XMLHttpRequest. > The use case is to improve the efficiency of getting a Blob from a binary > resource downloaded via XHR. > The alternative is to play games with character encodings so that > responseText can be used to fetch an image as a string, and then use > BlobBuilder to reconstruct the image file, again being careful with the > implicit character conversions. All of this is very inefficient. > Is there any appetite for adding a responseBlob getter on XHR? There has been talk about exposing a responseBody property which would contain the binary response. However ECMAScript is still lacking a binary type. Blob does fit the bill in that it represents binary data, however it's asynchronous nature is probably not ideal here, right? / Jonas
XMLHttpRequest.responseBlob
There is some interest from application developers at Google in being able to get a Blob corresponding to the response body of a XMLHttpRequest. The use case is to improve the efficiency of getting a Blob from a binary resource downloaded via XHR. The alternative is to play games with character encodings so that responseText can be used to fetch an image as a string, and then use BlobBuilder to reconstruct the image file, again being careful with the implicit character conversions. All of this is very inefficient. Is there any appetite for adding a responseBlob getter on XHR? Regards, -Darin
