Re: CfC: to add Speech API to Charter; deadline January 24
The deadline for comments is extended to January. Andrian, Maciej - I would appreciate it you would please provide some feedback on this CfC. On 1/12/12 7:31 AM, ext Arthur Barstow wrote: Glen Shires and some others at Google proposed [1] that WebApps add Speech API to WebApps' charter and they put forward the Speech Javascript API Specification [2] as as a starting point. Members of Mozilla and Nuance have voiced various levels of support for this proposal. As such, this is a Call for Consensus to add Speech API to WebApps' charter. Positive response to this CfC is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is January 19 and all comments should be sent to public-webapps at w3.org. -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html
Re: CfC: to add Speech API to Charter; deadline January 24
The deadline for comments is extended to January *24*. On 1/20/12 6:55 AM, ext Arthur Barstow wrote: The deadline for comments is extended to January. Andrian, Maciej - I would appreciate it you would please provide some feedback on this CfC. On 1/12/12 7:31 AM, ext Arthur Barstow wrote: Glen Shires and some others at Google proposed [1] that WebApps add Speech API to WebApps' charter and they put forward the Speech Javascript API Specification [2] as as a starting point. Members of Mozilla and Nuance have voiced various levels of support for this proposal. As such, this is a Call for Consensus to add Speech API to WebApps' charter. Positive response to this CfC is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is January 19 and all comments should be sent to public-webapps at w3.org. -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html
Reporting of CORS error in the XHR API callbacks
Reading http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#network-error it isn't obvious to me how the fact that a cross-site-scripting violation has occurred. The CORS spec http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#cross-origin-request-status suggests the error should be treated like a network error, but IMHO it is really important for the code using the XHR to be able simply and unambiguously to know when the CORS cross-origin-request-status is the problem, as opposed to any other network error. (It is also important that this can be passed on the to a user, so when the user is on the phone with customer support, the latter can understand what has happened). There of course places where XHR is used and there is no cross-sitescripting security needed 1) in a browser extension 2) in node.js code trusted apps 3) in web apps when web apps can, in I hope the near future, be installed, and flagged as trusted code Therefore it is reasonable to write code in which the attempt is made, a CORS error recognized, and alternative recourse taken (such as going through a proxy). Should a new set of error codes such as 9XX be used for client-internal errors like this, I wonder? Should there be a new value or status combined with readyState = 4? Many bits of code just wait for readyState = 4 at the moment and then just check status. What do current browsers do? Tim
Re: CfC: to add Speech API to Charter; deadline January 24
Some of the reasons we believe that the JavaScript Speech API is best suited for WebApps, instead of it's own working group, include: 1. Speech is likely to become a core API, like other WebApps deliverables such as File API. It is important that it be compatible and consistent with, and interact well with other JavaScript API components. In particular, speech provides a new method for accepting user input, producing user output and interacting with the features, and controlling the flow, of other JavaScript API components. 2. WebApps provides a balanced web-centric view for new JavaScript APIs. The XG group consisted of a large number of speech experts, but only a few with broad web API expertise. We believe the formation of a new WG would have a similar imbalance, whereas the WebApps WG can provide valuable, balanced guidance and feedback. 3. The scope of this effort is well-defined and bounded. All that have responded to this CfC have agreed that JavaScript API portions of the XG Final Report are relevant to WebApps, and that the wire protocol portions of the XG Final Report are not relevant to WebApps (and should be pursued in another group, such as IETF). The differing opinions seem only about the specific starting point of this effort, whether to base it on the full JavaScript API in the XG's Final Report [1] or a subset of that JavaScript API, which supports the majority of use cases, as proposed by Google [2]. For this first recommendation-track document, we believe a subset will accelerate implementation, interoperability testing, standardization and ultimately developer adoption. However, in the spirit of consensus, we are willing to broaden this subset to include additional API features in the XG Final Report. [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html Bjorn Bringert Satish Sampath Glen Shires On Fri, Jan 20, 2012 at 3:58 AM, Arthur Barstow art.bars...@nokia.comwrote: The deadline for comments is extended to January *24*. On 1/20/12 6:55 AM, ext Arthur Barstow wrote: The deadline for comments is extended to January. Andrian, Maciej - I would appreciate it you would please provide some feedback on this CfC. On 1/12/12 7:31 AM, ext Arthur Barstow wrote: Glen Shires and some others at Google proposed [1] that WebApps add Speech API to WebApps' charter and they put forward the Speech Javascript API Specification [2] as as a starting point. Members of Mozilla and Nuance have voiced various levels of support for this proposal. As such, this is a Call for Consensus to add Speech API to WebApps' charter. Positive response to this CfC is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is January 19 and all comments should be sent to public-webapps at w3.org. -AB [1] http://lists.w3.org/Archives/**Public/public-webapps/** 2011OctDec/1696.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html [2] http://lists.w3.org/Archives/**Public/public-webapps/** 2011OctDec/att-1696/speechapi.**htmlhttp://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html
RE: [indexeddb] Do we need to support keyPaths with an empty string?
Any updates on this thread? Odin from Opera prefers the FailFast method we've been discussing. We're in the process of cleaning some issues and would like to get this resolved ASAP. If we believe the current implementation in Firefox and Chrome is the way to go, I'm okay with it but I would like to know how we explain it to developers. Thanks, Israel On Wednesday, January 18, 2012 3:55 PM, Israel Hilerio wrote: Based on our retesting of Aurora and Canary, this is the behavior we're seeing: When a null or undefined keyPath is provided to the createObjectStore API, you can add values to an Object Store as long as a key is specified during the execution of the Add API. Not providing a key for the Add API will throw a DATA_ERR. Providing an empty string keyPath to the createObjectStore produces the opposite behavior. The Add API works as long as you don't provide any value for the key. I'm assuming that the value is used as the key value and that is the reason why using an object as the value fails. This difference in behavior seems strange to me. I would expect the behavior to be the same between a keyPath value of empty string, null, and undefined. How do you explain developers the reasons for the differences? Is this the behavior we want to support moving forward? Israel On Wednesday, January 18, 2012 2:08 PM, Joshua Bell wrote: On Wed, Jan 18, 2012 at 1:51 PM, ben turner bent.mozi...@gmail.commailto:bent.mozi...@gmail.com wrote: On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio isra...@microsoft.commailto:isra...@microsoft.com wrote: We tested on Firefox 8.0.1 Ah, ok. We made lots of big changes to key handling that will be in 11 I think. If you're curious I would recommend retesting with an aurora build from https://www.mozilla.org/en-US/firefox/aurora. Similarly, we've made lots of IDB-related fixes in Chrome 16 (stable), 17 (beta) and 18 (canary).
Re: Reporting of CORS error in the XHR API callbacks
On Fri, 20 Jan 2012, Tim Berners-Lee wrote: Reading http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#network-error it isn't obvious to me how the fact that a cross-site-scripting violation has occurred. The CORS spec http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#cross-origin-request-status suggests the error should be treated like a network error That is correct. but IMHO it is really important for the code using the XHR to be able simply and unambiguously to know when the CORS cross-origin-request-status is the problem, as opposed to any other network error. That would be a security flaw. It would allow hostile sites to scan victim sites behind firewalls for CORS-protected content. (It is also important that this can be passed on the to a user, so when the user is on the phone with customer support, the latter can understand what has happened). It can be passed to the user directly from the browser without the script being informed (and typically is, e.g. Firefox shows it in the Web console). There of course places where XHR is used and there is no cross-sitescripting security needed 1) in a browser extension 2) in node.js code trusted apps These aren't the Web, so they're probably out of scope of the CORS and XHR specs, but Anne can comment if he disagrees. :-) 3) in web apps when web apps can, in I hope the near future, be installed, and flagged as trusted code Personally I think the idea of installing a Web app is anathema. The best thing about Web apps is that the browser can be trusted such that even the most hostile app can't do anything bad. If we start allowing users to install apps, we'll just change the security model of the Web from you can't do anything bad without an implicit permission gesture from the user to all you have to do is convince the user to install you and then you can own them. Basically, moving us from the Web's security model today, a fantastic and successful security model that has withstood a decade or more of sustained attack, to the Windows security model. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: [indexeddb] Do we need to support keyPaths with an empty string?
Jeremy, What you're saying about the discrepancies between empty string, null, and undefined make a lot of sense. That is one of the reasons for this proposal, to stop adding to the confusion. I also agree with you that we should support the set scenario and that this can be accomplished without having to support keypaths with empty strings, null, or undefined values. I would like to hear from someone at Mozilla before we remove this from the spec. Thanks, Israel On Friday, January 20, 2012 10:48 AM, Joshua Bell wrote: rom: jsb...@google.com [mailto:jsb...@google.com] On Behalf Of Joshua Bell Sent: Friday, January 20, 2012 10:48 AM To: Israel Hilerio Cc: Odin Hørthe Omdal; Jonas Sicking (jo...@sicking.cc); ben turner (bent.mozi...@gmail.com); Adam Herchenroether; David Sheldon; public-webapps@w3.org Subject: Re: [indexeddb] Do we need to support keyPaths with an empty string? Empty strings, null, and undefined are all dangerous traps for the unwary in JavaScript already; all are falsy, some compare equal with ==, all ToString differently, some ToNumber differently. Personally, I try not to make any assumptions about how an API will respond to these inputs and approach with extreme caution. IMHO the set scenario is a valid use case, but that can be satisfied by specifying no key path and repeating the value during the put/add call, e.g. store.put(value, value). Therefore, I'm not opposed to removing empty string as a valid key path, but don't see it as particularly confusing, either. On Fri, Jan 20, 2012 at 9:58 AM, Israel Hilerio isra...@microsoft.commailto:isra...@microsoft.com wrote: Any updates on this thread? Odin from Opera prefers the FailFast method we've been discussing. We're in the process of cleaning some issues and would like to get this resolved ASAP. If we believe the current implementation in Firefox and Chrome is the way to go, I'm okay with it but I would like to know how we explain it to developers. Thanks, Israel On Wednesday, January 18, 2012 3:55 PM, Israel Hilerio wrote: Based on our retesting of Aurora and Canary, this is the behavior we're seeing: When a null or undefined keyPath is provided to the createObjectStore API, you can add values to an Object Store as long as a key is specified during the execution of the Add API. Not providing a key for the Add API will throw a DATA_ERR. Providing an empty string keyPath to the createObjectStore produces the opposite behavior. The Add API works as long as you don't provide any value for the key. I'm assuming that the value is used as the key value and that is the reason why using an object as the value fails. This difference in behavior seems strange to me. I would expect the behavior to be the same between a keyPath value of empty string, null, and undefined. How do you explain developers the reasons for the differences? Is this the behavior we want to support moving forward? Israel On Wednesday, January 18, 2012 2:08 PM, Joshua Bell wrote: On Wed, Jan 18, 2012 at 1:51 PM, ben turner bent.mozi...@gmail.commailto:bent.mozi...@gmail.com wrote: On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio isra...@microsoft.commailto:isra...@microsoft.com wrote: We tested on Firefox 8.0.1 Ah, ok. We made lots of big changes to key handling that will be in 11 I think. If you're curious I would recommend retesting with an aurora build from https://www.mozilla.org/en-US/firefox/aurora. Similarly, we've made lots of IDB-related fixes in Chrome 16 (stable), 17 (beta) and 18 (canary).
Re: [indexeddb] Do we need to support keyPaths with an empty string?
Mozilla is fine with removing the special |keyPath:| behavior.
Please note that this will also mean that step 1 of the algorithm here
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-extracting-a-key-from-a-value-using-a-key-path
will need to change.
We do want to continue to allow set behavior without specifying the
key twice, though, so we would propose adding an additional option to
createObjectStore to accomplish this:
// Old way:
var set = db.createObjectStore(mySet, { keyPath: });
set.put(keyValue);
// New way:
var set = db.createObjectStore(mySet, { isSet: true });
set.put(keyValue);
(We are not in love with isSet, better names are highly encouraged!)
What do you all think? This would allow us to continue to support nice
set behavior without making the empty string magic.
-Ben
Re: [indexeddb] Do we need to support keyPaths with an empty string?
On Fri, Jan 20, 2012 at 12:23 PM, ben turner bent.mozi...@gmail.com wrote:
Mozilla is fine with removing the special |keyPath:| behavior.
Please note that this will also mean that step 1 of the algorithm here
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-extracting-a-key-from-a-value-using-a-key-path
will need to change.
We do want to continue to allow set behavior without specifying the
key twice, though, so we would propose adding an additional option to
createObjectStore to accomplish this:
// Old way:
var set = db.createObjectStore(mySet, { keyPath: });
set.put(keyValue);
// New way:
var set = db.createObjectStore(mySet, { isSet: true });
set.put(keyValue);
(We are not in love with isSet, better names are highly encouraged!)
What do you all think? This would allow us to continue to support nice
set behavior without making the empty string magic.
I actually think that the current behavior that we have is pretty
consistent. Any time you give the keyPath property a string we create
an objectStore with a keyPath. And any time you have an objectStore
with a keyPath you are not allowed to pass an explicit key since the
key is gotten from the keyPath. There's no special handling of empty
strings happening.
But I do agree that it can be somewhat confusing to tell
/null/undefined apart since they are all falsy. In particular, an
expression like
if (myObjectStore.keyPath) {
...
}
doesn't work to test if an objectStore has a keyPath or not. You
instead need to check
if (myObjectStore.keyPath != null) {
...
}
or
if (typeof myObjectStore.keyPath == string) {
...
}
Hence the isSet suggestion.
Though I also realized after talking to Ben that empty keyPaths show
up in indexes too. Consider creating a objectStore which maps peoples
names to email addresses. Then you can create an index when does the
opposite mapping, or which ensures that email addresses are unique:
var store = db.createObjectStore(people);
var index = store.createIndex(reverse, , { unique: true });
store.add(john@email.com, John Doe);
store.add(m...@smith.org, Mike Smith);
store.get(John Doe).onsuccess = function(e) {
alert(John's email is + e.target.result);
}
index.getKey(m...@smith.org).onsuccess = function(e) {
alert(m...@smith.org is owned by + e.target.result);
}
Are people proposing we remove empty keyPaths here too?
/ Jonas
RE: [indexeddb] Do we need to support keyPaths with an empty string?
On Friday, January 20, 2012 2:31 PM, Jonas Sicking wrote:
On Fri, Jan 20, 2012 at 12:23 PM, ben turner bent.mozi...@gmail.com wrote:
Mozilla is fine with removing the special |keyPath:| behavior.
Please note that this will also mean that step 1 of the algorithm here
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-f
or-extracting-a-key-from-a-value-using-a-key-path
will need to change.
We do want to continue to allow set behavior without specifying the
key twice, though, so we would propose adding an additional option to
createObjectStore to accomplish this:
// Old way:
var set = db.createObjectStore(mySet, { keyPath: });
set.put(keyValue);
// New way:
var set = db.createObjectStore(mySet, { isSet: true });
set.put(keyValue);
(We are not in love with isSet, better names are highly encouraged!)
What do you all think? This would allow us to continue to support nice
set behavior without making the empty string magic.
I actually think that the current behavior that we have is pretty consistent.
Any
time you give the keyPath property a string we create an objectStore with a
keyPath. And any time you have an objectStore with a keyPath you are not
allowed to pass an explicit key since the key is gotten from the keyPath.
There's
no special handling of empty strings happening.
But I do agree that it can be somewhat confusing to tell /null/undefined
apart
since they are all falsy. In particular, an expression like
if (myObjectStore.keyPath) {
...
}
doesn't work to test if an objectStore has a keyPath or not. You instead need
to
check
if (myObjectStore.keyPath != null) {
...
}
or
if (typeof myObjectStore.keyPath == string) {
...
}
Hence the isSet suggestion.
Though I also realized after talking to Ben that empty keyPaths show up in
indexes too. Consider creating a objectStore which maps peoples names to
email addresses. Then you can create an index when does the opposite
mapping, or which ensures that email addresses are unique:
var store = db.createObjectStore(people); var index =
store.createIndex(reverse, , { unique: true });
store.add(john@email.com, John Doe); store.add(m...@smith.org,
Mike Smith);
store.get(John Doe).onsuccess = function(e) {
alert(John's email is + e.target.result); }
index.getKey(m...@smith.org).onsuccess = function(e) {
alert(m...@smith.org is owned by + e.target.result); }
Are people proposing we remove empty keyPaths here too?
/ Jonas
Yes, I'm proposing removing empty string KeyPaths all together to avoid
confusion.
I would like to know how often you expect developers to follow this pattern
instead of using objects. Our believe is that objects will be the main value
stored in object stores
instead of single values.
Supporting keyPath with empty strings brings up all kinds of side effects. For
example:
var store = db.createObjectStore(people);
var index = store.createIndex(reverse, , { unique: true });
store.add({email: john@email.com}, John Doe);
store.add({email: m...@smith.org},Mike Smith);
What should happen in this case, do we throw an exception? This is the scenario
we see in FF and Chrome.
I don't believe it will be obvious to developers that this functionality
behaves differently depending on the
value being stored.
Having some type of flag seems more promising for object stores. However, we
still need to figure out how to deal with
Indexes on sets, do we pass another flag to support the indexes on sets? If we
do that, then what do we do with the keyPath parameter to an index.
It seems we're overloading the functionality of these methods to support
different patterns.
Israel
