Re: [fileapi] timing of readyState changes vs. events
On Fri, 02 Mar 2012 23:31:38 +0100, Eric U er...@google.com wrote: On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren ann...@opera.com wrote: Uhm. What you need to do is queue a task that changes the state and fires the event. You cannot just fire an event from asynchronous operations. Pardon my ignorance, but why not? Is it because you have to define which task queue gets the operation? Yeah, otherwise it would be undefined when the operation occurs relative to other asynchronous tasks, such as timeouts, events, and fetching. So would that mean that e.g. the current spec for readAsDataURL would have to queue steps 6 and 8-10? Yeah. Actually, I think you want to queue a single task when the read is completed and then do 7, 8, 6, 9, 10 within that task (in that order, the current order seems wrong). -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] Multientry with invalid keys
This should now be fixed in editor drafts. On Sat, Mar 3, 2012 at 2:58 AM, Jonas Sicking jo...@sicking.cc wrote: Oh, I missed Joshua's last email. So it seems everyone is in agreement. I'll make the edits and then close the bug. / Jonas On Saturday, March 3, 2012, Jonas Sicking wrote: Crap, we need to better about filing bugs :-) Yes, my understanding is that there was agreement to update the spec such that if evaluating and index's keyPath does not yield a valid key that does not affect weather the value is inserted in the objectStore. In other words, indexes do not add constraints other than when explicitly called out using the 'unique' feature. My logic was that it would be consistent with this behaviour to ignore any invalid keys in a multiEntry index rather than to throw the whole thing out. If people are on with this ill edit this into the spec over the weekend. / Jonas On Saturday, March 3, 2012, Israel Hilerio wrote: I’ve created a bug to track this issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16211 Israel On Friday, March 02, 2012 4:39 PM, Odin Hørthe Omdal wrote: From: Israel Hilerio isra...@microsoft.com Unfortunately, we didn’t update the spec to reflect this agreement. You or I could open a bug to ensure the spec is updated to capture this change. Yes, better get it into the spec :-) About the behavior itself, FWIW, I think it's a reasonable one. -- Odin, Opera
[Bug 16223] New: Change .readyState to use string values rather than numeric constants
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16223
Summary: Change .readyState to use string values rather than
numeric constants
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: jo...@sicking.cc
QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Numeric constants sucks when used in javascript. Code like
if (ws.readyState == WebSocket.CONNECTING) { ... }
is both harder to read and harder to type compared to
if (ws.readyState == connecting) { ... }
All the uppercase letters are a pain to type and and stick out like a sore
thumb.
Additionally there's a very real risk that people will write code like
if (ws.readyState == 0) { ... }
since '0' is so much easier to write than 'WebSocket.CONNECTING'.
It's even likely that comparing to a string is faster than comparing to
WebSocket.CONNECTING since the latter involves a property lookup.
--
Configure bugmail: https://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: [IndexedDB] Multientry and duplicate elements
On Fri, Mar 2, 2012 at 8:49 PM, Israel Hilerio isra...@microsoft.com wrote:
There seems to be some cases where it might be useful to be able to get a
count of all the duplicates contained in a multiEntry index. Do you guys
see this as an important scenario?
Not exactly sure what you mean here.
Do you mean duplicates in the form of the same value existing for
multiple entries, i.e. (assuming there's an index on the 'a' property)
store.add({ a: [10, 20], ... }, 1);
store.add({ a: [10, 30], ... }, 2);
here there's a duplicate of the value 10. I.e. here you can count the
duplicates by doing:
index.count(10).onsuccess = ...;
This will give 2 as result.
Or do you mean duplicates in the form of the same value existing for
the same entry, i.e.:
store.add({ a: [30, 30] }, 3);
Currently in firefox this won't produce a duplicate entry in the index. I.e.
index.count(30).onsuccess = ...;
will give 1 as result.
It seems to me that it would introduce a lot of complexities if we
were to insert two rows here to allow tracking duplicates. First of
all there would be no way to tell the two entries apart using the API
that we have now which seems like it could be problematic for pages.
Second, cursor's iteration is currently defined in terms of going to
the next entry which has a higher key than the one the cursor is
currently located at. So if two entries have the exact same key, the
cursor would still skip over the second one of them. In other words,
we would have to redefine cursor iteration.
This is all certainly doable, but it seems non-trivial.
It would also complicate the datamodel in the implementation since the
index would no longer be simply a btree of indexKey + primaryKey. An
additional key would need to be added in order to tell duplicate
entries apart.
/ Jonas
