Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, 17 Aug 2010 04:05:52 +0200, Michael Nordman micha...@google.com wrote: I'm interested in adding support for XHR.responseBlob to webkit and chrome. It sounds like we have a general consensus to add two new members to the XmlHttpRequest interface: attribute boolean asBlob; // at least for the sake of discussion, calling it that for now readonly attribute Blob responseBlob; Another name option could be 'downloadAsBlob'. Personally, I like 'asBlob' for its brevity and its naming similarity to 'withCredentials'. Looks like the semantics of when its valid to call setRequestHeaders also applies setting the asBlob attribute; after open() but before send() has been called. An attempt to set the value at some inappropriate time should throw an INVALID_STATE exception. Also the asBlob attribute value should probably be reset to 'false' upon return from open(), again similar to how the request headers are cleared out upon return from open(). Anne, have you been following this discussion, wdyt? Yeah I have. This design looks rather good. We should also define what happens to responseText and responseXML in this scenario. I suppose throwing INVALID_STATE_ERR makes the most sense to make it clear they are not available. Nothing else should be affected right? (I think you also found a bug in that the credentials flag and request timeout are not reset when open() is invoked.) -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, 17 Aug 2010 05:35:20 +0200, Jonas Sicking jo...@sicking.cc wrote: Sounds good, though I think we let asBlob act is more like withCredentials and not get reset upon open(). Thus it can also be settable before open() as well. withCredentials is designed after setRequestHeader() so it is not settable before open(). -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] Languages for collation
On Tue, Aug 17, 2010 at 12:02 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 16, 2010 at 2:20 AM, Jeremy Orlow jor...@chromium.org wrote: However I think it's very rare that this will be needed. And there are ways to somewhat work around it by using separate databases. So I would probably say that lets keep it database-wide for now, and reconsider in version 2. On the other hand, is there any reason not to make it per-objectStore/index? As far as I can tell, it should actually be fairly light weight form an API point of view: we can just add it as an optional parameter to createObjectStore/createIndex. From an implementation point of view, I really don't see this being much overhead either. So maybe we should just do it? I don't feel very strongly. Though I'd want to check that this is actually pretty easy to do implementation wise. Given that I think this is a low-value feature, I'd want to make sure it's low-cost too. How will we check? And should we really be basing decisions off of what's easiest to do implementation wise? And is this truly a low value feature? By check I meant talk to Ben and Shawn who actually knows how our implementation works in detail. So the result is that in our current architecture we can't support different collations for different objectStores. Come to think of it, it's the same for us. But that's not to say that it couldn't be done another way. And implementation should be a very minor worry for us. But given that we think multiple databases will be a good work around, I'm fine sticking with a per-database setting as Pablo originally proposed. We can support changing collation in an existing database though. It will be a very slow operation, but it's needed to avoid forcing authors to delete an existing database and recreate a new one with a new collation. By low value I mean that no one has presented a use case that requires it. The alternative is to add a function within setVersion to set the language which actually seems less elegant. I don't understand what you mean by this. Have a setLanguage method on IDBDatabase that can only be called from within a setVersion transaction. In the same way removeObjectStore and company can only be called within a setVersion transaction. That would work. So effectively this function would modify all the data in all the objectStores and indexes such that it's now sorted according to the new collation. The 'success' event is fired after all data has been updated. Any requests made after the setLanguage call will see the modified data. Is that the idea? I'm not married to any of the particulars, but yeah that is the general idea.
Re: [IndexedDB] Languages for collation
On Tue, Aug 17, 2010 at 12:37 AM, Jungshik Shin (신정식, 申政湜) jungs...@google.com wrote: + adding the authors of BCP 47 (Mark Davis and Addison Phillips) and Richard Ishida (w3c i18n) On Mon, Aug 16, 2010 at 4:03 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 16, 2010 at 10:11 AM, Jeremy Orlow jor...@chromium.org wrote: 2 additional questions: What standard will define the language codes and the associated collation algorithm? Very good questions. Are there specifications for this stuff elsewhere? As for the language code, we already have BCP 47. See http://www.rfc-editor.org/rfc/bcp/bcp47.txt The Registry http://www.iana.org/assignments/language-subtag-registry http://unicode.org/reports/tr35/#BCP47 The collation algorithm should be based on UCA ( http://unicode.org/reports/tr10/ ) with locale-specific tailoring coming from CLDR (http://cldr.unicode.org ) And what's the behavior for an implementation that doesn't support that particular language? http://unicode.org/reports/tr35/#BCP47 BCP 47 above defines a truncation/fallback mechanism. All the locales along the line of truncation/fallback fails, it'd eventually fall back to the UCA. Jungshik / Jonas Thanks for the response, Jungshik! Referencing this stuff looks good for the spec side of things. Do you know anything about the implementation side, by chance? In other words are there any standard libraries that we can use for all of this? (Ideally BSD, LGPL, or similarly licensed? :-) J
Re: [Web Storage] A couple questions about the storage spec
On Tue, Aug 17, 2010 at 12:08 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 8 Jul 2010, David John Burrowes wrote:
I have a couple questions about the storage spec (I'm reading the June
15th version at (http://dev.w3.org/html5/webstorage/).
(1) The spec says: The object's indices of the supported indexed
properties are the numbers in the range zero to one less than the number
of key/value pairs currently present in the list associated with the
object. If the list is empty, then there are no supported indexed
properties.
As far as I can tell, this seems to say I should be able to say
something like:
window.localStorage[3]
and get something back (not clear if the key or the value). Am I right
in my interpretation of that paragraph?
Yes.
I saw some discussion earlier about whether something like
localStorage[3] was meaningful, but I didn't find the resolution. It
does seem undesirable/confusing to me. And none of the browsers I've
tried this with do this.
On Wed, 14 Jul 2010, Jeremy Orlow wrote:
All the browsers I know of handle localStorage[3] as
localStorage.get/setItem('3', ...). My impression is that this behavior
is pretty firmly rooted at this point. It seems as though the spec may
need to change.
Firefox seems to implement this correctly. It just seems to be a bug in
Opera and Chrome. (I didn't test Safari or IE.)
Safari and IE act the same way as Opera and Chrome, so I would agree with
David's assertion that this behavior is fairly firmly rooted. But you
disagree, Ian? If so, let me just make sure I understand correctly: if you
do localStorage[x] and x is a number, then it should be an index into item
number x, and if x is anything else, it should be interpreted as
.get(x)/.set(x, ...) ?
This is the kind of thing that will shake out when we have a test suite.
On Thu, 8 Jul 2010, David John Burrowes wrote:
(2) The spec also says:
The names of the supported named properties on a Storage object are the
keys of each key/value pair currently present in the list associated
with the object.
I read that (possibly/probably wrongly) as saying I should be able to say
window.localStorage.setItem(foo, bar);
myVariable = window.localStorage[foo];
and now myVariable will have bar.
Yes.
If my reading is right (and it is the behavior I see in a couple
browsers) this makes me very nervous, because I can do something like:
window.localStorage.setItem(length, a value we computer);
window.localStorage.setItem(clear, something that is
transparent);
which of course allows:
window.localStorage[length];
window.localStorage[clear];
but in the browsers I've looked at, this (of course) also kinda messes up
things like:
for (index = 0; index window.localStorage.length; index++) {
// whatever
}
window.localStorage.clear();
since length is now not a number, and clear isn't a function.
Actually length and clear don't get overrideen, because the interface is
not defined as [OverrideBuiltins].
Wha? This seems completely different than your answer in this thread:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020349.html
Why is this a desirable feature?
Code like this:
if (localStorage.visitedAlready) { ... }
...is simpler to read than code like:
if (localStorage.getItem('visitedAlready')) { ... }
(3) Real nitpicking here:
The IDL for the Storage interface says
setter creator void setItem(in DOMString key, in any data);
but the text says
The setItem(key, value) method
Note the name of the second parameter is different between these.
Fixed IDL.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, 17 Aug 2010 21:14:03 +0200, Michael Nordman micha...@google.com wrote: On Mon, Aug 16, 2010 at 11:34 PM, Anne van Kesteren ann...@opera.comwrote: Yeah I have. This design looks rather good. We should also define what happens to responseText and responseXML in this scenario. I suppose throwing INVALID_STATE_ERR makes the most sense to make it clear they are not available. Nothing else should be affected right? INVALID_STATE_ERR works. If responseText throws when asBlob is true, then resposneBlob should throw when asBlob is false. Another plausible option is to return NULL or UNDEFINED from these calls in those cases. Either way works, personally I like the unambiguous INVALID_STATE_ERR. Good point about responseBlob. Lets go for the exception. The responseBlob attribute should be available for access when the 'done' events are raised, so withing the event handler, the caller should be able to access that attribute and get final results. Here's what i'm referring to as the 'done' events... - onerror (responseBlob yields whatever partial results there were if any) Currently for network errors (i.e. not errors such as HTTP 410) everything will return their default value. Is there a good reason to do this differently for responseBlob? - onload - onloadend - readystate changing to DONE The only one I wonder about is onabort, what is the behavior of accessing reponseBlob in that terminating condition? Same as for onerror at the moment. I think nothing else changes, incremental ready state changed events and progress events should still fire as usual. Yes. (I'm going to wait at least a week or so with updating the draft to include this (and other) feature(s). XMLHttpRequest and XMLHttpRequest Level 2 are created from the same source document and I would like to give priority to integrating the proposed changes for XMLHttpRequest (Level 1) for which I hope to have WG consensus declared next week.) -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
Here's the text I've put in the webkit (and chrome) bug reports for this feature... https://bugs.webkit.org/show_bug.cgi?id=44133 http://code.google.com/p/chromium/issues/detail?id=52486 Implement an XHR.responseBlob accessor to get an opaque reference to the response data as a blob. Two new additions for the XHR interface in support of this. This is not solidified yet, still pending some discussion on the public lists. boolean attribute asBlob; // Prepares the XHR to make the response available as a blob object. // Defaults to false, must be set after calling open() and // prior to calling send(). Gets reset upon subsequent calls to open(). // Throws INVALID_STATE_ERR if set at an invalid time. Maybe read at // anytime without exception. Blob attribute responseBlob; // Returns a blob the contains the response body. // Only valid to access when asBlob is true and when the request is in // a terminal state. Throws INVALID_STATE_ERR if accessed at an // invalid time. When asBlob is true, the other response accessors (responseText, resonseXML, responseBody) throw INVALID_STATE_ERR if accessed. We're making this modal for the benefit of the browser vendors, to make it easier for them to know how to handle the response data as it comes in. With a priori knowlege that the data need never be made available thru the responseText attribute, life is a little easier for them/us. Also see http://code.google.com/p/chromium/issues/detail?id=52486 On Tue, Aug 17, 2010 at 3:13 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 17 Aug 2010 21:14:03 +0200, Michael Nordman micha...@google.com wrote: On Mon, Aug 16, 2010 at 11:34 PM, Anne van Kesteren ann...@opera.com wrote: Yeah I have. This design looks rather good. We should also define what happens to responseText and responseXML in this scenario. I suppose throwing INVALID_STATE_ERR makes the most sense to make it clear they are not available. Nothing else should be affected right? INVALID_STATE_ERR works. If responseText throws when asBlob is true, then resposneBlob should throw when asBlob is false. Another plausible option is to return NULL or UNDEFINED from these calls in those cases. Either way works, personally I like the unambiguous INVALID_STATE_ERR. Good point about responseBlob. Lets go for the exception. The responseBlob attribute should be available for access when the 'done' events are raised, so withing the event handler, the caller should be able to access that attribute and get final results. Here's what i'm referring to as the 'done' events... - onerror (responseBlob yields whatever partial results there were if any) Currently for network errors (i.e. not errors such as HTTP 410) everything will return their default value. Is there a good reason to do this differently for responseBlob? Ok... so is the default value for responseBlob an empty blob when asBlob is true and the attribute is accessed while the XHR object is in a terminal error or aborted state? Just looking to clarify whether the accessor should throw the invalid state error or return normally in these terminal states. - onload - onloadend - readystate changing to DONE The only one I wonder about is onabort, what is the behavior of accessing reponseBlob in that terminating condition? Same as for onerror at the moment. I think nothing else changes, incremental ready state changed events and progress events should still fire as usual. Yes. (I'm going to wait at least a week or so with updating the draft to include this (and other) feature(s). XMLHttpRequest and XMLHttpRequest Level 2 are created from the same source document and I would like to give priority to integrating the proposed changes for XMLHttpRequest (Level 1) for which I hope to have WG consensus declared next week.) -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Wed, 18 Aug 2010 00:24:56 +0200, Michael Nordman micha...@google.com wrote: Blob attribute responseBlob; // Returns a blob the contains the response body. // Only valid to access when asBlob is true and when the request is in // a terminal state. Throws INVALID_STATE_ERR if accessed at an // invalid time. I suppose when asBlob is true and the state is not DONE it should simply return null like responseXML does for consistency. But when asBlob is false it should throw. See for responseXML: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsexml-attribute Currently for network errors (i.e. not errors such as HTTP 410) everything will return their default value. Is there a good reason to do this differently for responseBlob? Ok... so is the default value for responseBlob an empty blob when asBlob is true and the attribute is accessed while the XHR object is in a terminal error or aborted state? Just looking to clarify whether the accessor should throw the invalid state error or return normally in these terminal states. If we go with null above it should be null here too. Returning null is probably also better if we decide we want to expose the Blob as streaming entity at some point. I.e. while the state is LOADING. -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, Aug 17, 2010 at 3:37 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 18 Aug 2010 00:24:56 +0200, Michael Nordman micha...@google.com wrote: Blob attribute responseBlob; // Returns a blob the contains the response body. // Only valid to access when asBlob is true and when the request is in // a terminal state. Throws INVALID_STATE_ERR if accessed at an // invalid time. I suppose when asBlob is true and the state is not DONE it should simply return null like responseXML does for consistency. But when asBlob is false it should throw. Sounds good (here and below) ... thnx for the clarification. See for responseXML: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsexml-attribute Currently for network errors (i.e. not errors such as HTTP 410) everything will return their default value. Is there a good reason to do this differently for responseBlob? Ok... so is the default value for responseBlob an empty blob when asBlob is true and the attribute is accessed while the XHR object is in a terminal error or aborted state? Just looking to clarify whether the accessor should throw the invalid state error or return normally in these terminal states. If we go with null above it should be null here too. Returning null is probably also better if we decide we want to expose the Blob as streaming entity at some point. I.e. while the state is LOADING. -- Anne van Kesteren http://annevankesteren.nl/
[Bug 7720] Redundant definition of openDatabase methods
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7720 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||REMIND --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2010-08-18 01:32:47 --- If the spec goes anywhere, this might be worth doing. Closing for now, though, since the spec seems dead. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
