Re: [IndexedDB] Two Real World Use-Cases
Hi Jonas I have been trying out your suggestion of using a separate object store to do manual indexing (and so support compound indexes or index object properties with arrays as values). There are some problems with this approach: 1. It's far too slow. To put an object and insert 50 index records (typical when updating an inverted index) this way takes 100ms using IDB versus 10ms using WebSQL (with a separate indexes table and compound primary key on index name and object key). For instance, my application has a real requirement to replicate 4,000,000 emails between client and server and I would not be prepared to accept latencies of 100ms to store each object. That's more than the network latency. 2. It's a waste of space. Using a separate object store to do manual indexing may work in theory but it does not work in practice. I do not think it can even be remotely suggested as a panacea, however temporary it may be. We can fix all of this right now very simply: 1. Enable objectStore.put and objectStore.delete to accept a setIndexes option and an unsetIndexes option. The value passed for either option would be an array (string list) of index references. 2. The object would first be removed as a member from any indexes referenced by the unsetIndexes option. Any referenced indexes which would be empty thereafter would be removed. 3. The object would then be added as a member to any indexes referenced by the setIndexes option. Any referenced indexes which do not yet exist would be created. This would provide the much-needed indexing capabilities presently lacking in IDB without sacrificing performance. It would also enable developers to use IDB statefully (MySQL-like pre-defined schemas with the DB taking on the complexities of schema migration and data migration) or statelessly (See Berkeley DB with the application responsible for the complexities of data maintenance) rather than enforcing an assumption at such an early stage. Regards Joran Greef
Re: [IndexedDB] Two Real World Use-Cases
On 3 March 2011 09:15, Joran Greef jo...@ronomon.com wrote: Hi Jonas I have been trying out your suggestion of using a separate object store to do manual indexing (and so support compound indexes or index object properties with arrays as values). There are some problems with this approach: 1. It's far too slow. To put an object and insert 50 index records (typical when updating an inverted index) this way takes 100ms using IDB versus 10ms using WebSQL (with a separate indexes table and compound primary key on index name and object key). For instance, my application has a real requirement to replicate 4,000,000 emails between client and server and I would not be prepared to accept latencies of 100ms to store each object. That's more than the network latency. 2. It's a waste of space. Using a separate object store to do manual indexing may work in theory but it does not work in practice. I do not think it can even be remotely suggested as a panacea, however temporary it may be. We can fix all of this right now very simply: 1. Enable objectStore.put and objectStore.delete to accept a setIndexes option and an unsetIndexes option. The value passed for either option would be an array (string list) of index references. 2. The object would first be removed as a member from any indexes referenced by the unsetIndexes option. Any referenced indexes which would be empty thereafter would be removed. 3. The object would then be added as a member to any indexes referenced by the setIndexes option. Any referenced indexes which do not yet exist would be created. This would provide the much-needed indexing capabilities presently lacking in IDB without sacrificing performance. It would also enable developers to use IDB statefully (MySQL-like pre-defined schemas with the DB taking on the complexities of schema migration and data migration) or statelessly (See Berkeley DB with the application responsible for the complexities of data maintenance) rather than enforcing an assumption at such an early stage. Regards Joran Greef Why would this be faster? Surely most of the time in inserting the 50 indexes is the search time of the index, and the JavaScript function call overhead would be minimal (its only 50 calls)? Cheers, Keean.
Re: [whatwg] set input.value when input element has composition string
Hi, Niwa-san. On 2011/03/02 15:30, Ryosuke Niwa wrote: On Tue, Mar 1, 2011 at 5:18 PM, Makoto Kato m_k...@ga2.so-net.ne.jp mailto:m_k...@ga2.so-net.ne.jp wrote: On Safari 5, even if textbox has IME composition string, text into textbox can be replaced by DOM/script. But other browser's behaviors are different, and this is no specification when textbox has composition string. Although IE, Chrome and Opera keep composition string after value is replaced by DOM, each behavior is different. This is the result for this test on each browsers. When textbox has IME composition string such as ABCDEFG, then script (textbox.value = 123;) is called, textbox becomes... 1. 123ABCDEFG (ABCDEFG keeps composition state and caret is after G). 2. 123 (composition string is removed). 3. ABCDEFG (ABCDEFG keeps composition state and caret is after G). Which behavior is right? 1 is Opera 11, 2 is Safari 5, and 3 is Chrome 10 and IE9. You must have tested Chrome improperly. We currently have a bug in Chrome. To see the bug, open the attached test and type nihao with Chinese IME on Windows or Mac. Then press down array key. The text is replaced by henhao but henha is still marked and looks as if I'm compositing henha but if I continue to type ma still with IME, then I observe that henhaomao is shown inside the input element. Once this bug is fixed, Chrome's behavior should match that of Safari 5. Do you think Safari's way (ex. 2) is right? I found some bugs on Chrome (and IE and Opera) when I test this, but I am not interesting about bugs. It is confused that each Web browser is different behavior for this . This is not good as interoperability. So I would like to decide the right behavior/specification when textbox.value = 'x'; that it has composition string. Also, some people says that it should not be canceled/removed even if value is changed by DOM. Because composition string is un-committed string. Niwa-san and folks, how do you think right design for this situation?? -- Makoto Kato
Re: [whatwg] set input.value when input element has composition string
On Thu, Mar 3, 2011 at 7:47 PM, Makoto Kato m_k...@ga2.so-net.ne.jp wrote: Hi, Niwa-san. On 2011/03/02 15:30, Ryosuke Niwa wrote: You must have tested Chrome improperly. We currently have a bug in Chrome. To see the bug, open the attached test and type nihao with Chinese IME on Windows or Mac. Then press down array key. The text is replaced by henhao but henha is still marked and looks as if I'm compositing henha but if I continue to type ma still with IME, then I observe that henhaomao is shown inside the input element. Once this bug is fixed, Chrome's behavior should match that of Safari 5. Do you think Safari's way (ex. 2) is right? In short, yes. It is confused that each Web browser is different behavior for this . This is not good as interoperability. So I would like to decide the right behavior/specification when textbox.value = 'x'; that it has composition string. Also, some people says that it should not be canceled/removed even if value is changed by DOM. Because composition string is un-committed string. It seems that the correct behavior depends on the semantics. Say I have typed a text 你好, then I decided to add 们 between 你 and 好 so I put the caret / insertion point between the two and start typing men on IME. At this point website randomly replaces the entire value by Hello. In that case, as a user, I wouldn't expect to have my uncommitted string men after Hello because semantically speaking, my greeting message in Chinese has entirely been replaced by one in English. There's no point in adding men at this point. On the other hand, if I had just typed 你 and website replaced the value by 你们 as I typed hao on IME, then having the uncommitted text after 你们 makes sense and I'd like to keep the text because then I can just commit my text to obtain 你们好. - Ryosuke
Re: CfC: publish a new Working Draft of DOM Core; comment deadline March 2
Hi All, There is significant support for this CfC and in general, I tend to favor PEPO (publish early, publish often). However, in this case, the group already agreed D3E is feature complete and it would be suboptimal (some have suggested harmful), for WebApps to publish a spec that conflicts/overlaps with D3E. Additionally, some members have been working on D3E for a relatively long time and they naturally want to preserve their investment. Doug expressed [DS] willingness to change D3E (to align with DOM Core Events) if there is broad consensus for changes. In this spirit of cooperation, before a new WD of DOM Core is published, I think the next step is to do as Doug suggested and identify all D3E issues. Anne asked [AvK] about the mechanism to use to identify issues. Unless Doug suggests otherwise, I recommend using a separate thread per issue on the www-dom mail list. -Art Barstow [DS] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0687.html [AvK] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0722.html On Feb/23/2011 11:20 AM, ext Arthur Barstow wrote: Anne and Ms2ger (representing Mozilla Foundation) have continued to work on the DOM Core spec and they propose publishing a new Working Draft of the spec: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html As such, this is a Call for Consensus (CfC) to publish a new WD of DOM Core. If you have any comments or concerns about this proposal, please send them to public-webapps by March 2 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -Art Barstow
Re: [postmsg] Is HTML5 Web Messaging ready for Last Call Working Draft?
Hi All - I just wanted to let people know that on February 28, Hixie and I had a brief exchange about this in #webapps: [[ http://krijnhoetmer.nl/irc-logs/webapps/20110228 # [21:14] Hixie ArtB: i'm always going to answer yes whenever you ask if anything is ready to go to LC, CR, REC, or whatnot. :-) # [21:18] ArtB Hixie: oh, no, not another W3C process discussion :-) # [21:19] ArtB We should probably avoid publishing an LC if you are about to check in important changes that would affect an implementation # [21:20] ArtB But I understand [at least I think I do :-)] your perspective on publishing # [21:20] Hixie i'm not aware of any pending important changes, but i have 1668 e-mails in my pending feedback folders dating from the past 4 months or so, so i can make no guarantees # [21:21] ArtB oh, dear # [21:21] Hixie i can however guarantee that i won't make any changes that harm implementations without having their ok # [21:21] Hixie so whether it's in LC or REC or ED doesn't make any difference to me or the implementors as far as i can tell :-) # [21:21] ArtB Hixie - ok; good to hear! ]] -AB On Feb/28/2011 3:09 PM, ext Arthur Barstow wrote: Hixie, All, Is the HTML5 Web Messaging spec ready for Last Call Working Draft? http://dev.w3.org/html5/postmsg/ If not, what must be done before it is ready for LC and what is the time frame to complete the work? Bugzilla [1] reports one bug for this component without a Resolution and that bug is a simple editorial typo: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11978 -Art Barstow [1] http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstr; amp;short_desc=product=WebAppsWGcomponent=Web+Messaging+%28editor%3A+Ian+Hickson%29longdesc_type=allwordssubstrlongdesc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemailtype1=substringemail1=emailtype2=substringemail2=bug_id_type=anyexactbug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=
Re: publish a new Working Draft of DOM Core; comment deadline March 2
On Thu, 03 Mar 2011 04:43:04 +0100, Shiki Okasaka
shiki.okas...@gmail.com wrote:
I guess the reason behind this has been discussed around:
http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0081.html
Actually what are the blocking issues why DOM Core does not state like,
interface EventTarget {
...
};
interface Node : EventTarget ...
yet?
None, I think, so done:
https://bitbucket.org/ms2ger/dom-core/changeset/5a0331350bed
Thanks!
--
Anne van Kesteren
http://annevankesteren.nl/
CfC: to stop work on Programmable HTTP Caching and Serving spec; deadline March 10
Hi All, WebApps' Programmable HTTP Caching and Serving spec was last updated by Nikunj in January 2010. Since then, my attempt to determine the level of interest in this spec via the tread below (archived at [1]) received no real traction. As such, this is a Call for Consensus to formally stop work on this spec. More specifically, the proposal includes: 1. Moving the spec from the PubStatus' active API Specifications table [2] to the Specs NO Longer Active table [3] 2. Marking its Plans data with Work on the specification has ended 3. Removing it from WebApps' charter the next time the charter is renewed (current charter ends June 2012) Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. The deadline for comments is March 10. Please send all comments to: public-webapps@w3.org -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0447.html [2] http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications [3] http://www.w3.org/2008/webapps/wiki/PubStatus#Specs_NO_Longer_Active Original Message Subject: [DataCache] Status and plans for Programmable HTTP Caching and Serving? Date: Fri, 5 Nov 2010 14:26:13 +0100 From: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com To: public-webapps public-webapps@w3.org, Nikunj Mehta nik...@o-micron.com, Bernard Traversat bernard.traver...@oracle.com, Julian Reschke julian.resc...@gmx.de, Mark Nottingham m...@yahoo-inc.com Hi All, During WebApps' November 1 gathering at the TPAC, we discussed [Mins] the WG's Programmable HTTP Caching and Serving spec, last updated by Nikunj in January 2010 [DataCache]. During this discussion, I agreed to the following related actions: ACTION-599 Ask Nikunj to report the status and plans of Programmable Cache to public-webapps http://www.w3.org/2008/webapps/track/actions/599 ACTION-600 Ask Oracle about their level of interest in Programmable Cache http://www.w3.org/2008/webapps/track/actions/600 ACTION-601 Ask public-webapps about creating Use Cases and requirements of Program App Caches versus HTML5 App Cache http://www.w3.org/2008/webapps/track/actions/601 ACTION-602 Contact julian reschke and Mark Nottingham about Data Cache http://www.w3.org/2008/webapps/track/actions/602 My short summary of this discussion is: it isn't clear if there is sufficient interest to continue this spec and if there is interest, what are the specific use cases it will address (i.e. use cases not addressed by HTML5 AppCache), and who is willing to commit to drive the spec forward. -Art Barstow [ tracker tags: ACTION-599, ACTION-600, ACTION-601, ACTION-602 ] [Mins] http://www.w3.org/2010/11/01-webapps-minutes.html#item05 [DataCache] http://dev.w3.org/2006/webapi/DataCache/
[Bug 12233] New: We should add a method to compare two IndxedDB keys
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12233 Summary: We should add a method to compare two IndxedDB keys Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We should add a method to compare two IndxedDB keys. Right now it's rather difficult to do so manually. -- 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.
[Bug 12229] When a IDBKeyRange.bound's lower param is greater than the upper one, we probably should throw some exception
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12229 Jeremy Orlow jor...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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.
[Bug 11348] [IndexedDB] Overhaul of the event model
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11348 Jonas Sicking jo...@sicking.cc changed: What|Removed |Added Status|NEW |RESOLVED CC||jo...@sicking.cc Resolution||FIXED --- Comment #6 from Jonas Sicking jo...@sicking.cc 2011-03-04 00:06:32 UTC --- This should now be FIXED! -- 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.
[Bug 12234] New: [IndexedDB] Integrate with the HTML5 event loop
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12234 Summary: [IndexedDB] Integrate with the HTML5 event loop Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We need to stop using terms like asynchronously do X and instead say things like queue a task to do X. This will make it clearer what happens asynchronously or synchronously in relation to what. -- 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.
[Bug 11978] Section: Abstract Problem: this specification defines two mecahism for... should read mechanisms.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11978 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-03-04 00:26:45 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. -- 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.
Re: [XHR2] ArrayBuffer support added
Following up on this older thread, Mozilla has added ArrayBuffer to their XHR object, though the documentation is a little bare. xhr.mozResponseArrayBuffer On 2/4/2011 2:01 AM, Anne van Kesteren wrote: On Thu, 03 Feb 2011 23:56:13 +0100, Charles Pritchard ch...@jumis.com wrote: But in the present, we've got XMLHttpRequest, with CORS semantics, and all other manner of goodness. EventSource seems to me, to have different use cases than the simpler XHR. Yes, it is meant for streaming. XMLHttpRequest isn't really. (And EventSource will get CORS in due course.) XHR is a pretty stable and well supported method, it seems that it'd be reasonably straightforward to take the current good-will around that standard, and see if a second ArrayBuffer response type is warranted. I rather wait until all the new features are more widely adopted and tested. Then we can see if they have been a success and if we need more. One nice thing to come out of it, saving a large file to a disk via XHR and FileWriter would be made much easier, with no need for temporary storage locations. Even with blob saved to disk, it'd take a lot of special case optimizations to make it efficient to copy that Blob to a new file. It'd likely require a copy, instead of what's likely wanted: writing the file once. Developing this now could have a positive effect on a future EventSource standard.
Some additions to Web Workers
Hi. It seems Mozilla extended the interface WorkerUtils in their implementation with the atob/btoa functions. I find them quite useful in that context, and would also encourage adding escape, unescape, encodeURI, decodeURI, encodeURIComponent, decodeURIComponent and many of the other global functions in the DOM environment which don't have any specific bindings to the DOM itself or manipulate documents, as that was a concern due to globals that are internally used by the DOM in some browsers. Thank you.
