Re: ISSUE-173 (ericu): terminal FileWriter progress events should be queued [File API: Writer]
On Fri, Dec 10, 2010 at 3:30 PM, Eric Uhrhane wrote: > On Fri, Dec 10, 2010 at 3:17 PM, James Robinson wrote: >> On Fri, Dec 10, 2010 at 2:04 PM, Eric Uhrhane wrote: >>> >>> On Fri, Dec 10, 2010 at 2:39 AM, Anne van Kesteren >>> wrote: >>> > On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue >>> > Tracker wrote: >>> >> >>> >> ISSUE-173 (ericu): terminal FileWriter progress events should be queued >>> >> [File API: Writer] >>> >> >>> >> http://www.w3.org/2008/webapps/track/issues/173 >>> >> >>> >> Raised by: Eric Uhrhane >>> >> On product: File API: Writer >>> >> >>> >> When a FileWriter successfully completes a write, currently it: >>> >> * dispatches a write event >>> >> * sets readyState to DONE >>> >> * dispatches a writeend event >>> >> >>> >> If you want to start a new write, you can't do it in onwrite, since >>> >> readyState is still WRITING. Those events should be queued for >>> >> asynchronous >>> >> delivery, so that readyState is DONE by the time they get handled. If >>> >> you >>> >> set up a new write in onwrite, you'll still run the risk of getting >>> >> confused >>> >> by the subsequent writeend from the previous write, but that's >>> >> detectable. >>> >> >>> >> I'll have to look and see what other events should be marked as queued. >>> > >>> > Why not queue a task that changes readyState and then dispatches write >>> > followed by writeend, "synchronously" from the task. That is how a >>> > number of >>> > things work in XMLHttpRequest. >>> >>> That would work too. Any reason that you don't want to set readyState >>> before queueing the task? This is already happening asynchronously, >>> in response to the write finishing--the important thing is just to >>> make sure the events are queued, and readyState is updated, before the >>> first handler runs. >> >> I'm not familiar with this particular API, but in general I think it's >> important that state variables be set at the same time that the relevant >> event fires. In other words, code that polls readyState or similar >> attributes should not be able to observe any change before the related event >> is fired. > > Yeah, that makes sense [+thanks to Jonas for pointing this out > off-list]. I'll link the readyState change with onwrite in the > success case and onerror in the failure case, then have onwriteend > come after. Oops, didn't mean to reply off-list. For posterity here is what I said: One of the use cases for readystate is to be able to tell if an event has fired yet or not. If you set it and then schedule a task to fire the next event then there is essentially a race condition where there's a small amount of time between the readystate changes and the event fires. / Jonas
RE: [Bug 11398] New: [IndexedDB] Methods that take multiple optional parameters should instead take an options object
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Friday, December 10, 2010 7:27 AM >> >> In addition to createObjectStore, I also intend to convert the following >> over: >> >> >> IDBObjectStore.createIndex >> IDBObjectStore.openCursor >> IDBIndex.openCursor >> IDBIndex.openKeyCursor >> IDBKeyRange.bound Sounds great. >> We did all of these two weeks ago in Chromium and have gotten some feedback. >> The main downside is that typos are silently ignored by JavaScript. We >> considered throwing if someone passed in an option we didn't recognize, but >> this would make it impossible to add more options later (which is one of the >> main reasons for doing this change). I think what we might do is just log >> something in the console with this happens. (Should the spec actually make >> a recommendation to this effect?) Besides that, I think overall we're happy >> with the change. I'm not sure what the problem is with throwing. Can't each implementation throw if it receives a parameter that has no meaning for it? Given that we can't know if future options will have substantial impact on the behavior of the function when they are present, it looks safer to go that route. Is there prior art in some other webapps API that takes JavaScript objects as parameters? What do they do? Thanks -pablo
Re: ISSUE-173 (ericu): terminal FileWriter progress events should be queued [File API: Writer]
On Fri, Dec 10, 2010 at 3:17 PM, James Robinson wrote: > On Fri, Dec 10, 2010 at 2:04 PM, Eric Uhrhane wrote: >> >> On Fri, Dec 10, 2010 at 2:39 AM, Anne van Kesteren >> wrote: >> > On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue >> > Tracker wrote: >> >> >> >> ISSUE-173 (ericu): terminal FileWriter progress events should be queued >> >> [File API: Writer] >> >> >> >> http://www.w3.org/2008/webapps/track/issues/173 >> >> >> >> Raised by: Eric Uhrhane >> >> On product: File API: Writer >> >> >> >> When a FileWriter successfully completes a write, currently it: >> >> * dispatches a write event >> >> * sets readyState to DONE >> >> * dispatches a writeend event >> >> >> >> If you want to start a new write, you can't do it in onwrite, since >> >> readyState is still WRITING. Those events should be queued for >> >> asynchronous >> >> delivery, so that readyState is DONE by the time they get handled. If >> >> you >> >> set up a new write in onwrite, you'll still run the risk of getting >> >> confused >> >> by the subsequent writeend from the previous write, but that's >> >> detectable. >> >> >> >> I'll have to look and see what other events should be marked as queued. >> > >> > Why not queue a task that changes readyState and then dispatches write >> > followed by writeend, "synchronously" from the task. That is how a >> > number of >> > things work in XMLHttpRequest. >> >> That would work too. Any reason that you don't want to set readyState >> before queueing the task? This is already happening asynchronously, >> in response to the write finishing--the important thing is just to >> make sure the events are queued, and readyState is updated, before the >> first handler runs. > > I'm not familiar with this particular API, but in general I think it's > important that state variables be set at the same time that the relevant > event fires. In other words, code that polls readyState or similar > attributes should not be able to observe any change before the related event > is fired. Yeah, that makes sense [+thanks to Jonas for pointing this out off-list]. I'll link the readyState change with onwrite in the success case and onerror in the failure case, then have onwriteend come after. > - James >> >> > -- >> > Anne van Kesteren >> > http://annevankesteren.nl/ >> > >> > >> > >
Re: ISSUE-173 (ericu): terminal FileWriter progress events should be queued [File API: Writer]
On Fri, Dec 10, 2010 at 2:04 PM, Eric Uhrhane wrote: > On Fri, Dec 10, 2010 at 2:39 AM, Anne van Kesteren > wrote: > > On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue > > Tracker > wrote: > >> > >> ISSUE-173 (ericu): terminal FileWriter progress events should be queued > >> [File API: Writer] > >> > >> http://www.w3.org/2008/webapps/track/issues/173 > >> > >> Raised by: Eric Uhrhane > >> On product: File API: Writer > >> > >> When a FileWriter successfully completes a write, currently it: > >> * dispatches a write event > >> * sets readyState to DONE > >> * dispatches a writeend event > >> > >> If you want to start a new write, you can't do it in onwrite, since > >> readyState is still WRITING. Those events should be queued for > asynchronous > >> delivery, so that readyState is DONE by the time they get handled. If > you > >> set up a new write in onwrite, you'll still run the risk of getting > confused > >> by the subsequent writeend from the previous write, but that's > detectable. > >> > >> I'll have to look and see what other events should be marked as queued. > > > > Why not queue a task that changes readyState and then dispatches write > > followed by writeend, "synchronously" from the task. That is how a number > of > > things work in XMLHttpRequest. > > That would work too. Any reason that you don't want to set readyState > before queueing the task? This is already happening asynchronously, > in response to the write finishing--the important thing is just to > make sure the events are queued, and readyState is updated, before the > first handler runs. > I'm not familiar with this particular API, but in general I think it's important that state variables be set at the same time that the relevant event fires. In other words, code that polls readyState or similar attributes should not be able to observe any change before the related event is fired. - James > > > -- > > Anne van Kesteren > > http://annevankesteren.nl/ > > > > > >
Re: [Bug 11406] New: [IndexedDB] IDBDatabase.transaction needs to specify exception for invalid mode parameter
Jonas Sicking: > Specifying an exception to throw for functions that take enums if a > invalid value is passed to the function. Ah, I misunderstood. Would you want a standard exception (like TypeError, or one of the DOMExceptions from DOM Core) or be able to have the IDL specify what exception is thrown? -- Cameron McCormack ≝ http://mcc.id.au/
Re: [Bug 11406] New: [IndexedDB] IDBDatabase.transaction needs to specify exception for invalid mode parameter
On Fri, Dec 10, 2010 at 1:57 PM, Cameron McCormack wrote: > Jeremy Orlow: >> > Similar with the direction for openCursor or anything that takes in >> > an enum. I don't see any existing error that's a particularly good >> > match for these. Maybe I should add an ENUM_ERR or something? > > Jonas Sicking: >> Would be great if WebIDL could help out here. Cameron, I seem to >> recall there being discussions about this, but I could be making that >> up. > > For specifying which DOMException code will be raised? There’s > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623 but I haven’t done > anything with that yet. Specifying an exception to throw for functions that take enums if a invalid value is passed to the function. / Jonas
Re: ISSUE-173 (ericu): terminal FileWriter progress events should be queued [File API: Writer]
On Fri, Dec 10, 2010 at 2:39 AM, Anne van Kesteren wrote: > On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue > Tracker wrote: >> >> ISSUE-173 (ericu): terminal FileWriter progress events should be queued >> [File API: Writer] >> >> http://www.w3.org/2008/webapps/track/issues/173 >> >> Raised by: Eric Uhrhane >> On product: File API: Writer >> >> When a FileWriter successfully completes a write, currently it: >> * dispatches a write event >> * sets readyState to DONE >> * dispatches a writeend event >> >> If you want to start a new write, you can't do it in onwrite, since >> readyState is still WRITING. Those events should be queued for asynchronous >> delivery, so that readyState is DONE by the time they get handled. If you >> set up a new write in onwrite, you'll still run the risk of getting confused >> by the subsequent writeend from the previous write, but that's detectable. >> >> I'll have to look and see what other events should be marked as queued. > > Why not queue a task that changes readyState and then dispatches write > followed by writeend, "synchronously" from the task. That is how a number of > things work in XMLHttpRequest. That would work too. Any reason that you don't want to set readyState before queueing the task? This is already happening asynchronously, in response to the write finishing--the important thing is just to make sure the events are queued, and readyState is updated, before the first handler runs. > -- > Anne van Kesteren > http://annevankesteren.nl/ > >
Re: [Bug 11406] New: [IndexedDB] IDBDatabase.transaction needs to specify exception for invalid mode parameter
Jeremy Orlow: > > Similar with the direction for openCursor or anything that takes in > > an enum. I don't see any existing error that's a particularly good > > match for these. Maybe I should add an ENUM_ERR or something? Jonas Sicking: > Would be great if WebIDL could help out here. Cameron, I seem to > recall there being discussions about this, but I could be making that > up. For specifying which DOMException code will be raised? There’s http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623 but I haven’t done anything with that yet. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [Bug 11406] New: [IndexedDB] IDBDatabase.transaction needs to specify exception for invalid mode parameter
On Fri, Dec 10, 2010 at 7:49 AM, Jeremy Orlow wrote: > Similar with the direction for openCursor or anything that takes in an enum. > I don't see any existing error that's a particularly good match for these. > Maybe I should add an ENUM_ERR or something? Would be great if WebIDL could help out here. Cameron, I seem to recall there being discussions about this, but I could be making that up. / Jonas
Re: [Bug 11351] New: [IndexedDB] Should we have a maximum key size (or something like that)?
On Fri, Dec 10, 2010 at 7:32 AM, Jeremy Orlow wrote: > Any more thoughts on this? I don't feel strongly one way or another. Implementation wise I don't really understand why implementations couldn't use keys of unlimited size. I wouldn't imagine implementations would want to use fixed-size allocations for every key anyway, right (which would be a strong reason to keep maximum size down). Pablo, do you know why the back ends you were looking at had such relatively low limits? At the same time, I suspect that very few people would run into problems if we set the limit at a K or two of bytes. It's in general a good idea to limit strings around somewhere 2^30 bytes as to avoid overflow problems, but such limits are large enough that I'm not even convinced they need to be specified. / Jonas
Re: [Bug 11394] New: We should throw if continue() is called with a key <= the current position
On Fri, Dec 10, 2010 at 6:48 AM, Jeremy Orlow wrote: > What exception should we throw? CONSTRAINT_ERR? Sounds good to me. / Jonas
Re: [IndexedDB] Events and requests
I've been reaching out to get feedback, but no success yet. Will re-poke.
/ Jonas
On Fri, Dec 10, 2010 at 4:33 AM, Jeremy Orlow wrote:
> Any additional thoughts on this? If no one else cares, then we can go with
> Jonas' proposal (and we should file a bug).
> J
>
> On Thu, Nov 11, 2010 at 12:06 PM, Jeremy Orlow wrote:
>>
>> On Tue, Nov 9, 2010 at 11:35 AM, Jonas Sicking wrote:
>>>
>>> Hi All,
>>>
>>> One of the things we briefly discussed at the summit was that we
>>> should make IDBErrorEvents have a .transaction. This since we are
>>> allowing you to place new requests from within error handlers, but we
>>> currently provide no way to get from an error handler to any useful
>>> objects. Instead developers will have to use closures to get to the
>>> transaction or other object stores.
>>>
>>> Another thing that is somewhat strange is that we only make the result
>>> available through the success event. There is no way after that to get
>>> it from the request. So instead we use special event interfaces with
>>> supply access to source, transaction and result.
>>>
>>> Compare this to how XMLHttpRequests work. Here the result and error
>>> code is available on the request object itself. The 'load' event,
>>> which is equivalent to our 'success' event didn't supply any
>>> information until we recently added progress event support. But still
>>> it only supplies information about the progress, not the actual value
>>> itself.
>>>
>>> One thing we could do is to move
>>>
>>> .source
>>> .transaction
>>> .result
>>> .error
>>>
>>> to IDBRequest. Then make "success" and "error" events be simple events
>>> which only implement the Event interface. I.e. we could get rid of the
>>> IDBEvent, IDBSuccessEvent, IDBTransactionEvent and IDBErrorEvent
>>> interfaces.
>>>
>>> We'd still have to keep IDBVersionChangeEvent, but it can inherit
>>> Event directly.
>>>
>>> The request created from IDBFactory.open would return a IDBRequest
>>> where .transaction and .source is null. We already fire a IDBEvent
>>> where .source is null (actually, the spec currently doesn't define
>>> what the source should be I see now).
>>>
>>>
>>> The only major downside with this setup that I can see is that the
>>> current syntax:
>>>
>>> db.transaction(["foo"]).objectStore("foo").get(mykey).onsuccess =
>>> function(e) {
>>> alert(e.result);
>>> }
>>>
>>> would turn into the slightly more verbose
>>>
>>> db.transaction(["foo"]).objectStore("foo").get(mykey).onsuccess =
>>> function(e) {
>>> alert(e.target.result);
>>> }
>>>
>>> (And note that with the error handling that we have discussed, the
>>> above code snippets are actually plausible (apart from the alert() of
>>> course)).
>>>
>>> The upside that I can see is that we behave more like XMLHttpRequest.
>>> It seems that people currently follow a coding pattern where they
>>> place a request and at some later point hand the request to another
>>> piece of code. At that point the code can either get the result from
>>> the .result property, or install a onload handler and wait for the
>>> result if it isn't yet available.
>>>
>>> However I only have anecdotal evidence that this is a common coding
>>> pattern, so not much to go on.
>>
>> Here's a counter proposal: Let's add .transaction, .source, and .result
>> to IDBEvent and just specify them to be null when there is no transaction,
>> source, and/or result. We then remove readyState from IDBResult as it
>> serves no purpose.
>> What I'm proposing would result in an API that's much more similar to what
>> we have at the moment, but would be a bit different than XHR. It is
>> definitely good to have similar patterns for developers to follow, but I
>> feel as thought the model of IndexedDB is already pretty different from XHR.
>> For example, method calls are supplied parameters and return an IDBRequest
>> object vs you using new to create the XHR object and then making method
>> calls to set it up and then making a method call to start it. In fact, if
>> you think about it, there's really not that much XHR and IndexedDB have in
>> common except that they use event handlers.
>> As for your proposal, let me think about it for a bit and forward it on to
>> some people I know who are playing with IndexedDB already.
>> J
>
Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
On Fri, Dec 10, 2010 at 6:01 PM, Shawn Wilsher wrote: > On 12/10/2010 5:03 AM, Jeremy Orlow wrote: > >> Speaking of which, we use UNKNOWN_ERR for a bunch of other >> internal consistency issues. Is this OK by everyone, should we use >> another, >> or should we create a new one? (Ideally these issues will be few and far >> between as we make things more robust.) >> > Would a CONSTRAINT_ERR make more sense? This error doesn't really apply to internal implementation issues in my mind. In addition, some of the places we can hit this also return CONSTRAINT_ERRs for other reasons. What error code should we use for IDBCursor.update/delete when the cursor >> is >> not currently on an item (or that item has been deleted)? >> > I think NOT_FOUND_ERR makes sense there. Sounds good to me. > TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be >> removed? >> > I can't think of anything that we'd actually want to use it for. > > > As for the numbering: does anyone object to me just starting from 1 and >> going sequentially? I.e. does anyone have a problem with them all getting >> new numbers, or should I keep the numbers the same when possible. (i.e. >> only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, >> DEADLOCK_ERR >> would change number, but the ordering of those on the page would change.) >> > I think it is fine to just renumber. If anyone is relying on the numbers > being a certain thing now, I think it's probably best just to have a clean > break instead of sometimes being right still. > > Cheers, > > Shawn > >
Re: [Bug 11398] New: [IndexedDB] Methods that take multiple optional parameters should instead take an options object
On 12/10/2010 7:27 AM, Jeremy Orlow wrote: We did all of these two weeks ago in Chromium and have gotten some feedback. The main downside is that typos are silently ignored by JavaScript. We considered throwing if someone passed in an option we didn't recognize, but this would make it impossible to add more options later (which is one of the main reasons for doing this change). I think what we might do is just log something in the console with this happens. (Should the spec actually make a recommendation to this effect?) Besides that, I think overall we're happy with the change. I think logging should maybe be recommended by the spec, but probably not required. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
On 12/10/2010 5:03 AM, Jeremy Orlow wrote: Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between as we make things more robust.) Would a CONSTRAINT_ERR make more sense? What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item (or that item has been deleted)? I think NOT_FOUND_ERR makes sense there. TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? I can't think of anything that we'd actually want to use it for. As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I think it is fine to just renumber. If anyone is relying on the numbers being a certain thing now, I think it's probably best just to have a clean break instead of sometimes being right still. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
[Bug 11530] No transaction should start until after all others that were created first and whose scope overlaps
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11530 Jeremy Orlow changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Jeremy Orlow 2010-12-10 17:43:28 UTC --- I had Andrei take a look at the change, but more eyes would be great! changeset: 102:e97db12d0949 tag: tip user:Jeremy Orlow date:Fri Dec 10 17:37:48 2010 + summary: Tighten up the semantics of how transactions can be run simultaneously. -- 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 11530] New: No transaction should start until after all others that were created first and whose scope overlaps
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11530 Summary: No transaction should start until after all others that were created first and whose scope overlaps Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: jor...@chromium.org ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org No transaction should start until after all others that were created first and whose scope overlaps have first completed. We agreed upon this at TPAC. -- 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 11527] Remove dynamic transactions from the spec
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11527 Jeremy Orlow changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Jeremy Orlow 2010-12-10 16:07:13 UTC --- Committed. It'd be great if someone could take a glance at the diff and report if they see any problems. changeset: 101:9adb96d63bbb tag: tip user:Jeremy Orlow date:Fri Dec 10 16:06:18 2010 + summary: Remove dynamic transactions. -- 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 11528] New: We should add some form of dynamic transaction to IndexedDB
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11528 Summary: We should add some form of dynamic transaction to IndexedDB 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 Depends on: 11527 We should add some form of dynamic transaction to IndexedDB. But not for v1. -- 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 11527] New: Remove dynamic transactions from the spec
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11527 Summary: Remove dynamic transactions from the spec Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: jor...@chromium.org ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We talked about this at TPAC and decided it was too much API surface area for v1. I'll file a bug about adding it back in for v2 in a moment. -- 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: [Bug 11406] New: [IndexedDB] IDBDatabase.transaction needs to specify exception for invalid mode parameter
Similar with the direction for openCursor or anything that takes in an enum. I don't see any existing error that's a particularly good match for these. Maybe I should add an ENUM_ERR or something? J On Thu, Nov 25, 2010 at 12:42 PM, wrote: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=11406 > > Summary: [IndexedDB] IDBDatabase.transaction needs to specify >exception for invalid mode parameter > 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 > > > [IndexedDB] IDBDatabase.transaction needs to specify exception for invalid > mode > parameter. > > -- > 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 11349] [IndexedDB] Null should not be a valid key type
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11349 Jeremy Orlow changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Jeremy Orlow 2010-12-10 15:39:18 UTC --- changeset: 99:0fa45b18a8ea tag: tip user:Jeremy Orlow date:Fri Dec 10 15:38:53 2010 + summary: Remove null from the list of valid key types. -- 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: [Bug 11351] New: [IndexedDB] Should we have a maximum key size (or something like that)?
Any more thoughts on this? On Mon, Nov 22, 2010 at 12:05 PM, Jeremy Orlow wrote: > Something working (but with degraded performance) is better than not > working at all. Especially when keys will often come from user data/input > and thus simple web apps will likely not handle the exceptions large keys > might generate. Throughout the rest of IndexedDB, we've taken quite a bit > of care to make sure that we don't throw exceptions on hard to anticipate > edge cases, I don't think this is terribly different. > > Storing a prefix and then doing lookups into the actual value seems like a > good way for implementations to handle it, but it's certainly not the only > way. Yes, this will turn into linear performance in the worst case, but in > practice I think you'll find that before the linear performance kills you, > various other issues with using IndexedDB like this will kill you. :-) > > I'm fine with us adding non-normative text reminding people that large keys > will be slow and having a recommended minimum key size that implementations > should try and make sure hits a reasonably fast path. But I think we should > make sure that implementations don't break with big keys. > > J > > > On Sat, Nov 20, 2010 at 10:49 AM, Jonas Sicking wrote: > >> On Fri, Nov 19, 2010 at 8:13 PM, Bjoern Hoehrmann >> wrote: >> > * Jonas Sicking wrote: >> >>The question is in part where the limit for "ridiculous" goes. 1K keys >> >>are sort of ridiculous, though I'm sure it happens. >> > >> > By "ridiculous" I mean that common systems would run out of memory. That >> > is different among systems, and I would expect developers to consider it >> > up to an order of magnitude, but not beyond that. Clearly, to me, a DB >> > system should not fail because I want to store 100 keys á 100KB. >> >> Note that at issue here isn't the total size of keys, but the key size >> of an individual entry. I'm not sure that I'd expect a 100KB key size >> to work. >> >> >>> Note that, since JavaScript does not offer key-value dictionaries for >> >>> complex keys, and now that JSON.stringify is widely implemented, it's >> >>> quite common for people to emulate proper dictionaries by using that >> to >> >>> work around this particular JavaScript limitation. Which would likely >> >>> extend to more persistent forms of storage. >> >> >> >>I don't understand what you mean here. >> > >> > I am saying that it's quite natural to want to have string keys that are >> > much, much longer than someone might envision the length of string keys, >> > mainly because their notion of "string keys" is different from the key >> > length you might get from serializing arbitrary objects. >> >> Still not fully sure I follow you. The only issue here is when using >> plain strings as keys, objects are not allowed to be used as keys. Or >> are you saying that people will use the return value from >> JSON.stringify as key? >> >> / Jonas >> >> >
Re: [Bug 11398] New: [IndexedDB] Methods that take multiple optional parameters should instead take an options object
In addition to createObjectStore, I also intend to convert the following over: IDBObjectStore.createIndex IDBObjectStore.openCursor IDBIndex.openCursor IDBIndex.openKeyCursor IDBKeyRange.bound We did all of these two weeks ago in Chromium and have gotten some feedback. The main downside is that typos are silently ignored by JavaScript. We considered throwing if someone passed in an option we didn't recognize, but this would make it impossible to add more options later (which is one of the main reasons for doing this change). I think what we might do is just log something in the console with this happens. (Should the spec actually make a recommendation to this effect?) Besides that, I think overall we're happy with the change. Lastly, are we happy with all the variable names for the above functions being directly turned into parameter names for the options object? If not, please enumerate any changes you think we should do. I plan to make this change early next week barring any major controversies. J On Wed, Nov 24, 2010 at 5:12 PM, wrote: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=11398 > > Summary: [IndexedDB] Methods that take multiple optional >parameters should instead take an options object > 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 >Depends on: 11350 > > > All methods that take multiple optional parameters (or which might possibly > take multiple in the future) should be converted over to options objects > like > what's described in bug 11350 (for createObjectStore). > > -- > 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: [Bug 11394] New: We should throw if continue() is called with a key <= the current position
What exception should we throw? CONSTRAINT_ERR? On Tue, Nov 23, 2010 at 11:50 PM, wrote: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=11394 > > Summary: We should throw if continue() is called with a key <= >the current position > 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 > > > (The below assumes a forward iterating cursor, opposite applies for a > reverse > iterating cursor of course). > > The spec currently states that when calling IDBCursor.continue and passing > in a > key, the cursor moves to the first record which is greater than the current > position, and greater than or equal to the passed in key. > > As we implemented this we realized that this makes the situation when > someone > passes in a key which is less than or equal to the current position very > strange. The effect is that the key argument is ignored. > > However most likely this was done in error. Worst case, the author might > have > thought that the cursor would go back to the first entry whose key is > greater > than or equal to the passed in key, ignoring the current position. > > One example of buggy code would be displaying a sales-table with 10 entries > from every employee name. If the code ends up passing in a key which is > less > than or equal to the passed in key, the code likely contains an error. > > So a better behavior would be to throw if the passed in key is less than or > equal to the cursors current position. This makes it more clear that an > error > occurred, as well as helps a debugger detect the exception and display the > current program state. > > -- > 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 11389] IDBTransaction.READ_ONLY should probably be 0
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11389 Jeremy Orlow changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Jeremy Orlow 2010-12-10 14:23:32 UTC --- changeset: 98:c9ddfc1efda4 tag: tip user:Jeremy Orlow date:Fri Dec 10 14:22:37 2010 + summary: Switch READ_ONLY and READ_WRITE so that READ_ONLY is 0 since it's the default for transaction(). -- 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: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
I was confused re not overlapping with other exception codes. As long as we don't have overlap within this particular exception type, we're OK. I noticed that QUOTA_ERR is commented out. I can't remember when or why and the blame history is a bit mangled. Does anyone else? In Chromium we currently use UNKNOWN_ERR for whenever we have issues writing stuff to disk. We could probably tease quota related issues out into their own error. And/or we should probably create or find a good existing error for such uses. Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between as we make things more robust.) We also use UNKNOWN_ERR for when things are not yet implemented. Any concerns? What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item (or that item has been deleted)? TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I intend to tackle this early next week unless there are major areas of contention. J On Mon, Nov 22, 2010 at 12:43 PM, wrote: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=11375 > > Summary: [IndexedDB] Error codes need to be assigned new >numbers > 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 > > > The error codes specced in IDBDatabaseException's interface need to be > redone. > They currently overlap with existing exception error codes and use 0 which > we've avoided using in the past [0]. In addition, the codes are > non-contiguous > which also seems to be non-standard. We should re-map the exception > numbers > into something contiguous that doesn't overlap with other exception codes. > > > [0] I'm not sure if 0 is actually specced to be reserved, but in practice > it > seems to be. And WebKit uses 0 internally to signal "no exception". > > -- > 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: [IndexedDB] Compound and multiple keys
Any other thoughts on this issue?
On Thu, Dec 2, 2010 at 7:19 AM, Keean Schupke wrote:
> I think I prefer A. Declaring the keys in advance is stating to sound a
> little like a schema, and when you go down that route you end up at SQL
> schemas (which is a good thing in my opinion). I understand however that
> some people are not so comfortable with the idea of a schema, and these
> people seem to be the kind of people that like IndexedDB. So, although I
> prefer A for me, I would have to say B for IndexedDB.
>
> So in conclusion: I think "B" is the better choice for IndexedDB, as it is
> more consistent with the design of IDB.
>
> As for the cons of "B", sorting an array is just like sorting a string, and
> it already supports string types.
>
> Surely there is also option "C":
>
> store.add({firstName: "Benny", lastName: "Zysk", age: 28}, ["firstName",
> "lastName"]);
> store.add({firstName: "Benny", lastName: "Andersson", age:
> 63}, ["firstName", "lastName"]);
>
> Like "A", but listing the properties to include in the composite index with
> each add, therefore avoiding the "schema"...
>
>
> As for layering the Relational API over the top, It doesn't make any
> difference, but I would prefer whichever has the best performance.
>
>
> Cheers,
> Keean.
>
>
> On 2 December 2010 00:57, Jonas Sicking wrote:
>
>> Hi IndexedDB fans (yay!!),
>>
>> Problem description:
>>
>> One of the current shortcomings of IndexedDB is that it doesn't
>> support compound indexes. I.e. indexing on more than one value. For
>> example it's impossible to index on, and therefor efficiently search
>> for, firstname and lastname in an objectStore which stores people. Or
>> index on to-address and date sent in an objectStore holding emails.
>>
>> The way this is traditionally done is that multiple values are used as
>> key for each individual entry in an index or objectStore. For example
>> the CREATE INDEX statement in SQL can list multiple columns, and
>> CREATE TABLE statment can list several columns as PRIMARY KEY.
>>
>> There have been a couple of suggestions how to do this in IndexedDB
>>
>> Option A)
>> When specifying a key path in createObjectStore and createIndex, allow
>> an array of key-paths to be specified. Such as
>>
>> store = db.createObjectStore("mystore", ["firstName", "lastName"]);
>> store.add({firstName: "Benny", lastName: "Zysk", age: 28});
>> store.add({firstName: "Benny", lastName: "Andersson", age: 63});
>> store.add({firstName: "Charlie", lastName: "Brown", age: 8});
>>
>> The records are stored in the following order
>> "Benny", "Andersson"
>> "Benny", "Zysk"
>> "Charlie", "Brown"
>>
>> Similarly, createIndex accepts the same syntax:
>> store.createIndex("myindex", ["lastName", "age"]);
>>
>> Option B)
>> Allowing arrays as an additional data type for keys.
>> store = db.createObjectStore("mystore", "fullName");
>> store.add({fullName: ["Benny", "Zysk"], age: 28});
>> store.add({fullName: ["Benny", "Andersson"], age: 63});
>> store.add({fullName: ["Charlie", "Brown"], age: 8});
>>
>> Also allows out-of-line keys using:
>> store = db.createObjectStore("mystore");
>> store.add({age: 28}, ["Benny", "Zysk"]);
>> store.add({age: 63}, ["Benny", "Andersson"]);
>> store.add({age: 8}, ["Charlie", "Brown"]);
>>
>> (the sort order here is the same as in option A).
>>
>> Similarly, if an index pointed used a keyPath which points to an
>> array, this would create an entry in the index which used a compound
>> key consisting of the values in the array.
>>
>> There are of course advantages and disadvantages with both options.
>>
>> Option A advantages:
>> * Ensures that at objectStore/index creation time the number of keys
>> are known. This allows the implementation to create and optimize the
>> index using this information. This is especially useful in situations
>> when the indexedDB implementation is backed by a SQL database which
>> uses columns as a way to represent multiple keys.
>> * Easy to use when key values appear as separate properties on the
>> stored object.
>> * Obvious how to sort entries.
>>
>> Option A disadvantages:
>> * Doesn't allow compound out-of-line keys.
>> * Requires multiple properties to be added to stored objects if the
>> components of the key isn't available there (for example if it's
>> out-of-line or stored in an array).
>>
>> Option B advantages:
>> * Allows compound out-of-line keys.
>> * Easy to use when the key values are handled as an array by other
>> code. Both when using in-line and out-of-line keys.
>> * Maximum flexibility since you can combine single-value keys and
>> compound keys in one objectStore, as well as arrays of different
>> length (we couldn't come up with use cases for this though).
>>
>> Option B disadvantages:
>> * Requires defining sorting between single values and arrays, as well
>> as between arrays of different length.
>> * Requires a single property to be added to stored objects if the key
>> isn't available there (for example if it's stored as separate
>
Re: [IndexedDB] Events and requests
Any additional thoughts on this? If no one else cares, then we can go with
Jonas' proposal (and we should file a bug).
J
On Thu, Nov 11, 2010 at 12:06 PM, Jeremy Orlow wrote:
> On Tue, Nov 9, 2010 at 11:35 AM, Jonas Sicking wrote:
>
>> Hi All,
>>
>> One of the things we briefly discussed at the summit was that we
>> should make IDBErrorEvents have a .transaction. This since we are
>> allowing you to place new requests from within error handlers, but we
>> currently provide no way to get from an error handler to any useful
>> objects. Instead developers will have to use closures to get to the
>> transaction or other object stores.
>>
>> Another thing that is somewhat strange is that we only make the result
>> available through the success event. There is no way after that to get
>> it from the request. So instead we use special event interfaces with
>> supply access to source, transaction and result.
>>
>> Compare this to how XMLHttpRequests work. Here the result and error
>> code is available on the request object itself. The 'load' event,
>> which is equivalent to our 'success' event didn't supply any
>> information until we recently added progress event support. But still
>> it only supplies information about the progress, not the actual value
>> itself.
>>
>> One thing we could do is to move
>>
>> .source
>> .transaction
>> .result
>> .error
>>
>> to IDBRequest. Then make "success" and "error" events be simple events
>> which only implement the Event interface. I.e. we could get rid of the
>> IDBEvent, IDBSuccessEvent, IDBTransactionEvent and IDBErrorEvent
>> interfaces.
>>
>> We'd still have to keep IDBVersionChangeEvent, but it can inherit
>> Event directly.
>>
>> The request created from IDBFactory.open would return a IDBRequest
>> where .transaction and .source is null. We already fire a IDBEvent
>> where .source is null (actually, the spec currently doesn't define
>> what the source should be I see now).
>>
>>
>> The only major downside with this setup that I can see is that the
>> current syntax:
>>
>> db.transaction(["foo"]).objectStore("foo").get(mykey).onsuccess =
>> function(e) {
>> alert(e.result);
>> }
>>
>> would turn into the slightly more verbose
>>
>> db.transaction(["foo"]).objectStore("foo").get(mykey).onsuccess =
>> function(e) {
>> alert(e.target.result);
>> }
>>
>> (And note that with the error handling that we have discussed, the
>> above code snippets are actually plausible (apart from the alert() of
>> course)).
>>
>> The upside that I can see is that we behave more like XMLHttpRequest.
>> It seems that people currently follow a coding pattern where they
>> place a request and at some later point hand the request to another
>> piece of code. At that point the code can either get the result from
>> the .result property, or install a onload handler and wait for the
>> result if it isn't yet available.
>>
>> However I only have anecdotal evidence that this is a common coding
>> pattern, so not much to go on.
>>
>
> Here's a counter proposal: Let's add .transaction, .source, and .result to
> IDBEvent and just specify them to be null when there is no transaction,
> source, and/or result. We then remove readyState from IDBResult as it
> serves no purpose.
>
> What I'm proposing would result in an API that's much more similar to what
> we have at the moment, but would be a bit different than XHR. It is
> definitely good to have similar patterns for developers to follow, but I
> feel as thought the model of IndexedDB is already pretty different from XHR.
> For example, method calls are supplied parameters and return an IDBRequest
> object vs you using new to create the XHR object and then making method
> calls to set it up and then making a method call to start it. In fact, if
> you think about it, there's really not that much XHR and IndexedDB have in
> common except that they use event handlers.
>
> As for your proposal, let me think about it for a bit and forward it on to
> some people I know who are playing with IndexedDB already.
>
> J
>
[Bug 9769] IDBObjectStoreRequest/Sync.put should be split into 3 methods
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9769 Jeremy Orlow changed: What|Removed |Added Status|REOPENED|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 10303] Transactions should not commit if code unwinds because of an exception
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10303 Jeremy Orlow changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Jeremy Orlow 2010-12-10 12:22:05 UTC --- *** This bug has been marked as a duplicate of bug 11348 *** -- 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 10590] [IndexedDB] Default timeout duration needs to be specced
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10590 Jeremy Orlow changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Jeremy Orlow 2010-12-10 12:21:25 UTC --- *** This bug has been marked as a duplicate of bug 11425 *** -- 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 11407] [IndexedDB] IDBDatabase.createObjectStore: autoIncrement should not default to true
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11407 Jeremy Orlow changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Jeremy Orlow 2010-12-10 12:11:38 UTC --- changeset: 96:912efed5aae1 tag: tip user:Jeremy Orlow date:Wed Dec 08 19:03:47 2010 + summary: Update overview.html with my last change. changeset: 95:c95dd6d58c30 user:Jeremy Orlow date:Wed Dec 08 18:09:56 2010 + summary: IndexedDB's autoIncrement should not default to true -- 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: ISSUE-173 (ericu): terminal FileWriter progress events should be queued [File API: Writer]
On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue Tracker wrote: ISSUE-173 (ericu): terminal FileWriter progress events should be queued [File API: Writer] http://www.w3.org/2008/webapps/track/issues/173 Raised by: Eric Uhrhane On product: File API: Writer When a FileWriter successfully completes a write, currently it: * dispatches a write event * sets readyState to DONE * dispatches a writeend event If you want to start a new write, you can't do it in onwrite, since readyState is still WRITING. Those events should be queued for asynchronous delivery, so that readyState is DONE by the time they get handled. If you set up a new write in onwrite, you'll still run the risk of getting confused by the subsequent writeend from the previous write, but that's detectable. I'll have to look and see what other events should be marked as queued. Why not queue a task that changes readyState and then dispatches write followed by writeend, "synchronously" from the task. That is how a number of things work in XMLHttpRequest. -- Anne van Kesteren http://annevankesteren.nl/
