[Bug 26161] New: Initially the XMLHttpRequest object must be in ...
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26161 Bug ID: 26161 Summary: Initially the XMLHttpRequest object must be in ... Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: at.li...@live.com.au QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://xhr.spec.whatwg.org/#states [[ Initially the XMLHttpRequest object must be in the UNSET state. ]] Should be UNSENT. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26162] New: The name XMLHttpRequest is historical and has n...
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26162 Bug ID: 26162 Summary: The name XMLHttpRequest is historical and has n... Product: WebAppsWG Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: trivial Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: at.li...@live.com.au QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://xhr.spec.whatwg.org/#introduction [[ The name XMLHttpRequest is historical and has no baring on its functionality. ]] Should be bearing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26163] New: Update references for RFCs 2616 and 2617
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26163 Bug ID: 26163 Summary: Update references for RFCs 2616 and 2617 Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: julian.resc...@gmx.de QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Created attachment 1486 -- https://www.w3.org/Bugs/Public/attachment.cgi?id=1486action=edit Proposed change The specification should be changed to cite the current specs. (see attached diff) -- You are receiving this mail because: You are on the CC list for the bug.
IDBObjectStore/IDBIndex.exists(key)
Hi all, I found an old email with notes about features that we might want to put in v2. Almost all of them was recently brought up in the recent threads about IDBv2. However there was one thing on the list that I haven't seen brought up. It might be a nice perf improvement to add support for a IDBObjectStore/IDBIndex.exists(key) function. This would require less IO and less object creation than simply using .get(). It is probably particularly useful when doing a filtering join operation between two indexes/object stores. But it is probably useful other times too. Is this something that others think would be useful? / Jonas
Re: IDBObjectStore/IDBIndex.exists(key)
I think the same thought pattern can be applied elsewhere in the API design for v2. Consider the scenario of trying to find whether a given index exists or not (upon upgradeneeded). For now, we have to write noisy code like [].slice.call(objectStore.indexNames()).indexOf(someIndex) Why couldn't indexNames be an array? and dare we ask for this to either return the index or null: objectStore.index(someIndex) ? I understand the argument for throwing an error here but I think a silent null is more practical. So yes, anything that makes the API easier to consume would be terrific. I had a very hard time until I saw the light. There's some solid thought behind the existing API, but it's also not designed for web development in terms of how it implements a good idea, not wether or not the idea is good. Sorry for the mini rant. It took me a little too long to get this app done which is my first time using IndexedDB (with a half broken debugger in Chrome): https://github.com/idibidiart/AllSeeingEye On Sat, Jun 21, 2014 at 5:39 PM, Jonas Sicking jo...@sicking.cc wrote: Hi all, I found an old email with notes about features that we might want to put in v2. Almost all of them was recently brought up in the recent threads about IDBv2. However there was one thing on the list that I haven't seen brought up. It might be a nice perf improvement to add support for a IDBObjectStore/IDBIndex.exists(key) function. This would require less IO and less object creation than simply using .get(). It is probably particularly useful when doing a filtering join operation between two indexes/object stores. But it is probably useful other times too. Is this something that others think would be useful? / Jonas
Re: IDBObjectStore/IDBIndex.exists(key)
I think this sounds like a fine idea. -Ben Turner On Sat, Jun 21, 2014 at 5:39 PM, Jonas Sicking jo...@sicking.cc wrote: Hi all, I found an old email with notes about features that we might want to put in v2. Almost all of them was recently brought up in the recent threads about IDBv2. However there was one thing on the list that I haven't seen brought up. It might be a nice perf improvement to add support for a IDBObjectStore/IDBIndex.exists(key) function. This would require less IO and less object creation than simply using .get(). It is probably particularly useful when doing a filtering join operation between two indexes/object stores. But it is probably useful other times too. Is this something that others think would be useful? / Jonas
