RE: [IndexedDB] setVersion with multiple IDBDatabase objects
-Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of ben turner Sent: Tuesday, September 28, 2010 8:19 AM Yes, let's have it tied to the instance on which setVersion() was called. As Shawn pointed out that is consistent with the behavior that database instances from different windows will observe. As Jeremy pointed out that is consistent with the way object stores and indexes are tied to a transaction instance. Also, the |event.source| will be db1 in the given example, so it seems natural to allow changes only to the database we pass in the event and no other. -Ben +1, let's tie it to the instance and make it consistent with stores/indexes. -pablo
RE: [IndexedDB] IDBCursor.update for cursors returned from IDBIndex.openCursor
I agree with Jonas on this. I think accessing the index values is an important
feature (in addition to joins you can imagine add an extra property or two to
the index key* to create a covering index and avoid fetching the object in a
perf-critical path).
That said, to me it's just about allowing retrieval. For update/delete it would
be perfectly reasonable to have to go to the store in my opinion.
-pablo
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Jonas Sicking
Sent: Friday, September 17, 2010 3:15 PM
On Fri, Sep 17, 2010 at 2:46 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Sep 17, 2010 at 1:06 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Sep 16, 2010 at 2:23 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Sep 16, 2010 at 8:53 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Sep 16, 2010 at 2:15 AM, Jeremy Orlow jor...@chromium.org
wrote:
Wait a sec. What are the use cases for non-object cursors anyway?
They
made perfect sense back when we allowed explicit index management,
but
now
they kind of seem like a premature optimization or possibly even dead
weight. Maybe we should just remove them altogether?
They are still useful for joins. Consider an objectStore employees:
{ id: 1, name: Sven, employed: 1-1-2010 }
{ id: 2, name: Bert, employed: 5-1-2009 }
{ id: 3, name: Adam, employed: 6-6-2008 }
And objectStore sales
{ seller: 1, candyName: lollipop, quantity: 5, date: 9-15-2010 }
{ seller: 1, candyName: swedish fish, quantity: 12, date: 9-15-2010
}
{ seller: 2, candyName: jelly belly, quantity: 3, date: 9-14-2010 }
{ seller: 3, candyName: heath bar, quantity: 3, date: 9-13-2010 }
If you want to display the amount of sales per person, sorted by names
of sales person, you could do this by first creating and index for
employees with keyPath name. You'd then use IDBIndex.openCursor to
iterate that index, and for each entry find all entries in the sales
objectStore where seller matches the cursors .value.
So in this case you don't actually need any data from the employees
objectStore, all the data is available in the index. Thus it is
sufficient, and faster, to use openCursor than openObjectCursor.
In general, it's a common optimization to stick enough data in an
index that you don't have to actually look up in the objectStore
itself. This is slightly less commonly doable since we have relatively
simple indexes so far. But still doable as the example above shows.
Once we add support for arrays as keys this will be much more common
as you can then stick arbitrary data into the index by simply adding
additional entries to all key arrays. And even more so once we
(probably in a future version) add support for computed indexes.
On Thu, Sep 16, 2010 at 8:57 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Sep 16, 2010 at 4:08 AM, Jeremy Orlow jor...@chromium.org
wrote:
Actually, for that matter, are remove and update needed at all? I
think
they may just be more cruft left over from the explicit index days.
As
far
as I can tell, any .delete or .remove should be doable via an
objectCursor +
.puts/.removes on the objectStore.
They are not strictly needed, but they are a decent convinence
feature, and with a proper implementation they can even be a
performance optimization. With a cursor iterating a b-tree you can let
the cursor keep a pointer to the b-tree entry. They way .delete and
.update doesn't have to do a b-tree lookup at all.
We're currently not able to do this since our backend (sqlite) doesn't
have good enough cursor support, but I suspect that this will change
at some point in the future. In the mean time it seems like a good
thing to allow people to use API that will be faster in the future.
All your arguments revolve around what the spec
and implementations might do
in the future.
I disagree. The IDBIndex.openCursor example I included uses only
existing API, and is a performance improvement in at least our current
implementation. Would be interested to hear if it's not a performance
improvement in others.
It's not in ours because we join to the ObjectStore's data table either way.
But that's not at all why I'm bringing this up.
Why?
Typically we add API surface area only for use cases that
are currently impossible to satisfy or proven performance bottlenecks. I
agree that it's likely implementations will want to do optimizations
like
this in the future, but until they do, it'll be hard to really
understand
the implications and complications that might arrise.
That's not entirely true. All the databases I have worked with have
had significant performance degradations when having to look up the
main table contents rather than simply looking at the contents in the
index. I doubt that we'll be able to create a backend where
RE: [IndexedDB] Languages for collation
From: Jungshik Shin (신정식, 申政湜) [mailto:jungs...@google.com] Sent: Tuesday, August 24, 2010 10:34 PM As for the locale identifiers, my understanding is that Windows APIs (newer 'name-based' locale APIs) more or less follows BCP 47. Picking this back up from this August thread. I went around and asked Windows folks about this. Locale identifiers based on BCP 47 sound good. On the other hand, we probably wouldn't do UCA. I heard various worries from folks that work in this space, including the fact that it seems it's still changing so it would be a moving target (which btw means that collisions could still happen) and that we don't support it in a number of places today. Given that feedback, I would rather leave this open and let implementations choose the algorithm for collation (still need to do language-sensitive collation, of course). Would that work? Thanks -pablo
Re: [CORS] Suggested HTTP error codes on forbidden origin, unsupported method, etc.?
On Sun, 26 Sep 2010 12:01:59 +0200, Vladimir Dzhuvinov vladi...@dzhuvinov.com wrote: I looked at various CORS examples, but they were not particularly instructional on how the server should respond if the origin is not allowed or some other check fails. The CORS spec also seems to deliberately avoid this and leave it to the implementers. For my CORS servlet filter I'm planning to respond with HTTP 403 Forbidden - on a origin that is not allowed HTTP 405 Method not allowed - on an unsupported method Does this make sense? How should the server respond if it receives a custom header that is not listed as supported? I suppose we could give advice, but it does not really matter as the client will always treat it as a network error to make it indistinguishable from other failures. -- Anne van Kesteren http://annevankesteren.nl/
Re: Seeking agenda items for WebApps' Nov 1-2 f2f meeting
I added the following slots for November 2: [[ http://www.w3.org/2008/webapps/wiki/TPAC2010#Tuesday.2C_November_2 13:30-15:00: Indexed DB 15:30-16:30: Indexed DB 16:30-18:00: File * APIs ]] Of course we can fine-tune the times as needed. Arun - we reserved a speaker phone for remote participants for both days. -Art Barstow On 9/28/10 5:45 PM, ext Eric Uhrhane wrote: Works fine for me. I'll be there all of Monday and Tuesday. Due to jetlag morning vs. afternoon's probably irrelevant to me, as I won't have any idea what time it is ;'. On Tue, Sep 28, 2010 at 2:30 PM, Jonas Sickingjo...@sicking.cc wrote: The later the better for me. If we can make it after noon I'll be there for sure. / Jonas On Tue, Sep 28, 2010 at 1:37 PM, Jeremy Orlowjor...@google.com wrote: I'm OK with any time slot. On Tue, Sep 28, 2010 at 8:57 PM, Arthur Barstowart.bars...@nokia.com wrote: Hi All, Currently, no one has requested a specific day + time slot for any of the proposed topics: http://www.w3.org/2008/webapps/wiki/TPAC2010 When our IndexedDB participants agree on a time slot on Tuesday the 2nd, I'll add it to the agenda. Pablo, Jonas, Jeremy - please propose a time. Day + time slot proposals for the agenda topics already proposed are also welcome (as are proposals for additional topics). -Art Barstow On 9/28/10 3:28 PM, ext Pablo Castro wrote: It looks like there will be good critical mass for IndexedDB discussions, so I'll try to make it as well. Tuesday would be best for me as well for an IndexedDB meeting so I can travel on Sunday/Monday. -pablo -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Tuesday, September 28, 2010 10:53 AM To: Jeremy Orlow Cc: Pablo Castro; art.bars...@nokia.com; public-webapps Subject: Re: Seeking agenda items for WebApps' Nov 1-2 f2f meeting I'm not 100% sure that I'll make TPAC this year, but if I do, I likely won't make monday. So a tuesday schedule would fit me better too. / Jonas On Tue, Sep 28, 2010 at 8:36 AM, Jeremy Orlowjor...@google.comwrote: Is it possible to schedule IndexedDB for Tuesday? I'm pretty sure that I can be there then, but Monday is more up in the air at this moment. Thanks! Jeremy On Thu, Sep 2, 2010 at 3:28 AM, Jonas Sickingjo...@sicking.ccwrote: I'm hoping to be there yes. Especially if we'll get a critical mass of IndexedDB contributors. / Jonas On Wed, Sep 1, 2010 at 7:18 PM, Pablo Castropablo.cas...@microsoft.com wrote: -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Tuesday, August 31, 2010 4:32 AM The WebApps WG will meet face-to-face November 1-2 as part of the W3C's 2010 TPAC meeting week [TPAC]. I created a stub agenda item page and seek input to flesh out agenda: http://www.w3.org/2008/webapps/wiki/TPAC2010 [TPAC] includes a link to the Registration page, a detailed schedule of the group meetings, and other useful information. The registration fee is 40€ per day and will increase to 120€ per day after October 22. -Art Barstow [TPAC] http://www.w3.org/2010/11/TPAC/ For folks working on IndexedDB, are you guys planning on attending the TPAC? Given the timing of the event it may be a great opportunity to get together and iron out a whole bunch of issues at once. It would be good to know ahead of time so we can all make plans if we have critical mass. Thanks -pablo
[IndexedDB] Calling setVersion while already in a setVersion transaction
What should we do when setVersion is called while a setVersion transaction is currently active? Off the top of my head, I can think of two behaviors we might want to spec: 1) Have the subsequent setVersion simply throw an error. 2) Have the subsequent setVersion adopt the existing setVersion transaction and change the version. (i.e. whatever the last setVersion call sets as the version string will win.) Any others? What do you guys think is the most sane behavior? J
Re: [IndexedDB] Calling setVersion while already in a setVersion transaction
On 9/29/2010 6:12 AM, Jeremy Orlow wrote: Off the top of my head, I can think of two behaviors we might want to spec: 1) Have the subsequent setVersion simply throw an error. 2) Have the subsequent setVersion adopt the existing setVersion transaction and change the version. (i.e. whatever the last setVersion call sets as the version string will win.) Any others? What do you guys think is the most sane behavior? I think (2) is most consistent with how transactions work in other places. I think it's sane too. I can't come up with a good reason why we'd throw for subsequent setVersion calls either. Thinking about it some more, this might make sense for someone who has had more than one version change. They could first update the the version from 1 to 2, and then from 2 to 3. Since it's possible that clients visiting the site could be on any of these three versions, it makes sense to have functions that only go from the previous version to the next, otherwise you'll end up with lots of logic to deal with every version combination. Doing this all in the same transaction seems to make sense to me. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [CORS] Suggested HTTP error codes on forbidden origin, unsupported method, etc.?
On 29 September 2010 13:48, Anne van Kesteren ann...@opera.com wrote: On Sun, 26 Sep 2010 12:01:59 +0200, Vladimir Dzhuvinov vladi...@dzhuvinov.com wrote: I looked at various CORS examples, but they were not particularly instructional on how the server should respond if the origin is not allowed or some other check fails. The CORS spec also seems to deliberately avoid this and leave it to the implementers. For my CORS servlet filter I'm planning to respond with HTTP 403 Forbidden - on a origin that is not allowed HTTP 405 Method not allowed - on an unsupported method Does this make sense? How should the server respond if it receives a custom header that is not listed as supported? I suppose we could give advice, but it does not really matter as the client will always treat it as a network error to make it indistinguishable from other failures. Yes, I see now. I just had this uncertainty, when I was coding the filter, as to how to respond sensibly in case of a CORS exception. While terminating the request silently wouldn't matter to end users, I thought providing a meaningful error code and message might help client-side developers to debug CORS calls with tools like FireBug (at least, that helped debugging my own apps ;-) -- Vladimir Dzhuvinov :: software.dzhuvinov.com
Re: CfC: First Public Working Draft of Web DOM Core; deadline October 2
On 9/25/10 7:29 AM, Barstow Art (Nokia-CIC/Boston) wrote: As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. Support! -ArtB
Re: [IndexedDB] Calling setVersion while already in a setVersion transaction
On Wed, Sep 29, 2010 at 6:12 AM, Jeremy Orlow jor...@chromium.org wrote: What should we do when setVersion is called while a setVersion transaction is currently active? Off the top of my head, I can think of two behaviors we might want to spec: 1) Have the subsequent setVersion simply throw an error. 2) Have the subsequent setVersion adopt the existing setVersion transaction and change the version. (i.e. whatever the last setVersion call sets as the version string will win.) Any others? What do you guys think is the most sane behavior? My initial reaction was 3) Schedule another version transaction which is started after the currently running version transaction (and any other already scheduled transactions) are done running. That was actually my initial reaction, though that is biased by what our implementation naturally would do unless special care is taken to do something else. In general I don't feel strongly either way and am fine with all currently proposed solutions. / Jonas
ISSUE-134 (optional useCapture): Consider making useCapture parameter of add/removeEventListener optional [DOM3 Events]
ISSUE-134 (optional useCapture): Consider making useCapture parameter of add/removeEventListener optional [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/134 Raised by: Doug Schepers On product: DOM3 Events Sergey Ilinsky http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0195.html: [[ There are modern browsers that made 3rd argument in the addEventListener/removeEventListener be optional. Is this a legal step? If I understand correctly, specification requires 3rd argument to be passed, thus the new behaviour not backed by the change in specification only destabilizes web as a platform. Personally, I like the behaviour, but cannot use it as long as not every browser does that. ]]
