Re: [IndexedDB] Syntax for opening a cursor

[Tab Atkins Jr.]

On Thu, Jun 24, 2010 at 1:25 PM, Jeremy Orlow  wrote:
> If I'm reading the current spec right (besides the "[NoInterfaceObject]"
> attributes that I thought Nikunj was going to remove), if I want to open a
> cursor, this is what I need to do:
>
> myObjectStore.openCursor(new IDBKeyRange().leftBound("key"), new
> IDBCursor().NEXT_NO_DUPLICATE);
>
> Note that I'm creating 2 objects which get thrown away after using the
> constructor and constant.  This seems pretty wasteful.
> Jonas' proposal (which I guess Nikunj is currently in the middle of
> implementing?) makes things a bit better:
>
> myObjectStore.openCursor(window.indexedDB.makeLeftBoundedKeyRange("key"),
> new IDBCursor().NEXT_NO_DUPLICATE);
>
> or, when you have a single key that you're looking for, you can use the
> short hand
>
> myObjectStore.openCursor("key", new IDBCursor().PREV);
>
> But even in these examples, we're creating a needless object.  I believe we
> could also use the prototype to grab the constant, but the syntax is still
> pretty verbose and horrid.
> Can't we do better?

If we're specifying something that will get wrapped in a library to
make it less horrible *on day 1* (or earlier), we're doing it wrong.

All of the variants above are very, very wrong.

~TJ

Re: Thoughts on WebNotification

[Doug Turner]

Hey Drew,

> I think this is too vague, as it's sounds like a user agent could *not* 
> ignore markup in the string, and still be compliant with the spec. I think we 
> need to be very explicit that the string *must* be treated as plain text. So 
> if I pass in ">foo" as the body parameter to createNotification(), 
> the resulting notification must display the string ">foo", without 
> stripping or converting any of the substrings that might look like HTML 
> entities.
> 

Yup.  we should tighten up the language.  i think we are on the same page here.

> 
> 
> 
> 3) Move Web notifications to a version 2 of the specification.  For the most 
> basic use cases, this API isn't required and a web developer could use the 
> more base API to simulate this.  Furthermore, as I mentioned above, many 
> system-level notification services know nothing about rendering html.
> 
> I'm not certain what moving WebNotifications to version 2 would mean, 
> especially since as specified, user agents already are free to leave 
> createWebNotification() undefined. Can you please clarify what you think, in 
> practice, having createWebNotification() moved to version 2 would accomplish? 
> Since compliant user agents are already free to *not* implement this API, it 
> sounds like your only goal could be to discourage other user agents from 
> implementing the createWebNotification() API, and I'm not at all convinced 
> that's either appropriate or feasible.

My thinking, right or wrong, was that it might be nice to say that most UAs 
will support version v.1 (that doesn't include things like webnotifications).  
And in v.2 is the things that some UAs aren't willing to implement at the 
present time.

In practice, though, it really doesn't matter.

Doug

[IndexedDB] Syntax for opening a cursor

[Jeremy Orlow]

If I'm reading the current spec right (besides the "[NoInterfaceObject]"
attributes that I thought Nikunj was going to remove), if I want to open a
cursor, this is what I need to do:

myObjectStore.openCursor(new IDBKeyRange().leftBound("key"), new
IDBCursor().NEXT_NO_DUPLICATE);


Note that I'm creating 2 objects which get thrown away after using the
constructor and constant.  This seems pretty wasteful.

Jonas' proposal (which I guess Nikunj is currently in the middle of
implementing?) makes things a bit better:

myObjectStore.openCursor(window.indexedDB.makeLeftBoundedKeyRange("key"),
new IDBCursor().NEXT_NO_DUPLICATE);


or, when you have a single key that you're looking for, you can use the
short hand

myObjectStore.openCursor("key", new IDBCursor().PREV);


But even in these examples, we're creating a needless object.  I believe we
could also use the prototype to grab the constant, but the syntax is still
pretty verbose and horrid.

Can't we do better?

J

Re: Thoughts on WebNotification

[Drew Wilson]

On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner  wrote:

> I have been thinking a bit on Desktop Notifications [1].  After reviewing
> the Web Notification specification [2], I would like to propose the
> following changes:
>
>
> 1) Factor out the permission api into a new interface and/or spec.  The
> ability to test for a permission without bring up a UI would improve the UX
> of device access.  I could imagine implementing this feature for use with
> Geolocation as well as notifications.  For example:
>
> interface Permissions {
>
> // permission values
> const unsigned long PERMISSION_ALLOWED = 0;
> const unsigned long PERMISSION_UNKNOWN = 1;
> const unsigned long PERMISSION_DENIED  = 2;
>
> void checkPermission(in DOMString type, in Function callback);
>
> }
>
> Then we could do something like:
>
> navigator.permissions.checkPermission("desktop-notification",
> function(value) {});
>
> or
>
> navigator.permissions.checkPermission("geolocation", function(value) {});
>
>
>
> 2) Add language to the spec to indicate that the DOMStrings used
> |createNotification| are not to include any mark up.  Basically,
> implementations are going to hand off notifications to system-level
> services.  For example, on the Mac, GROWL does not handle any mark up...
> their API just takes plain strings.  I'd like to see the API reflect this
> reality.  Something like "the |title| and |body| arguments are to be treated
> as plain text"... or some such language.
>
> Agreed. The current language reads:

The user agent may ignore any markup in this string and treat it as plain
text.

I think this is too vague, as it's sounds like a user agent could *not*
ignore markup in the string, and still be compliant with the spec. I think
we need to be very explicit that the string *must* be treated as plain text.
So if I pass in ">foo" as the body parameter to
createNotification(), the resulting notification must display the string
">foo", without stripping or converting any of the substrings that
might look like HTML entities.



>
> 3) Move Web notifications to a version 2 of the specification.  For the
> most basic use cases, this API isn't required and a web developer could use
> the more base API to simulate this.  Furthermore, as I mentioned above, many
> system-level notification services know nothing about rendering html.
>
> I'm not certain what moving WebNotifications to version 2 would mean,
especially since as specified, user agents already are free to leave
createWebNotification() undefined. Can you please clarify what you think, in
practice, having createWebNotification() moved to version 2 would
accomplish? Since compliant user agents are already free to *not* implement
this API, it sounds like your only goal could be to discourage other user
agents from implementing the createWebNotification() API, and I'm not at all
convinced that's either appropriate or feasible.


>
>
> I hope that this is helpful,
> Doug Turner
> Mozilla Corp
>
>
> [1] http://dougt.org/wordpress/2010/06/desktop-notifications/
> [2] http://dev.w3.org/2006/webapi/WebNotifications/publish/
>

Re: Thoughts on WebNotification

[Doug Turner]

Thank you for your quick response!

On Jun 24, 2010, at 11:48 AM, John Gregg wrote:

> On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner  wrote:
> I have been thinking a bit on Desktop Notifications [1].  After reviewing the 
> Web Notification specification [2], I would like to propose the following 
> changes:
> 
> 
> 1) Factor out the permission api into a new interface and/or spec.  The 
> ability to test for a permission without bring up a UI would improve the UX 
> of device access.  I could imagine implementing this feature for use with 
> Geolocation as well as notifications.  For example:
> 
> interface Permissions {
> 
> // permission values
> const unsigned long PERMISSION_ALLOWED = 0;
> const unsigned long PERMISSION_UNKNOWN = 1;
> const unsigned long PERMISSION_DENIED  = 2;
> 
> void checkPermission(in DOMString type, in Function callback);
> 
> }
> 
> Then we could do something like:
> 
> navigator.permissions.checkPermission("desktop-notification", function(value) 
> {});
> 
> or
> 
> navigator.permissions.checkPermission("geolocation", function(value) {});
> 
> 
> I like this idea, I think it's definitely preferable to a one-off permission 
> system just for notifications. 
> 
> Your proposal doesn't have a way to explicitly request permission.  Would you 
> be willing to add that, with the recommendation that it only take place on a 
> user gesture?  I don't think this eliminates the ability to implement 
> request-on-first-use, if that's what Mozilla prefers, but I also still think 
> there is benefit to allowing permissions to be obtained separately from 
> invoking the API in question.

so, checkPermission and requestPermission.  I am happy with that..

and

if really want to get crazy, we could do something like:

navigator.permissions.requestPermission("geolocation,desktop-notification",...).

This would allow a site to request multiple permissions in one go up to the 
implementation if this is supported (i'd argue), and up to the implementation 
on how best to handle these requests.


> The bigger question is, are other features interested?  Would the Geolocation 
> spec consider using something like this for permissions?

cc'ing Andrei Popescu - the editor of the Geolocation spec.  Not sure how to 
formally answer your question.  However, if the permission api above was 
implemented, I think it naturally follows that "geolocation" would be one of 
the known strings.

> 2) Add language to the spec to indicate that the DOMStrings used 
> |createNotification| are not to include any mark up.  Basically, 
> implementations are going to hand off notifications to system-level services. 
>  For example, on the Mac, GROWL does not handle any mark up... their API just 
> takes plain strings.  I'd like to see the API reflect this reality.  
> Something like "the |title| and |body| arguments are to be treated as plain 
> text"... or some such language.
> 
> 
> Although the group isn't chartered to deliver the spec forward, FWIW I agree 
> with this suggestion (it was always the intent) and have made this language 
> explicit in the editor's draft.

cool beans.


> 3) Move Web notifications to a version 2 of the specification.  For the most 
> basic use cases, this API isn't required and a web developer could use the 
> more base API to simulate this.  Furthermore, as I mentioned above, many 
> system-level notification services know nothing about rendering html.
>  
> Though I think web content still makes sense for notifications coming from a 
> web browser, and would want to publish an API which drives things in that 
> direction, I think this is reasonable if it will encourage greater 
> implementation of the basic API.  As long as the text+icon API we use doesn't 
> cut off that avenue, and I think what we have now meets that.

Make it optional allows us to have a spec that interoperates.  I am not sure 
that Mozilla (or I) would want to implement this part of the specification.  My 
goal is for tight system level integration and I do not believe that web 
notifications helps on that.

Again, thank you for your thoughts,

Doug Turner

Re: Thoughts on WebNotification

[John Gregg]

On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner  wrote:

> I have been thinking a bit on Desktop Notifications [1].  After reviewing
> the Web Notification specification [2], I would like to propose the
> following changes:
>
>
> 1) Factor out the permission api into a new interface and/or spec.  The
> ability to test for a permission without bring up a UI would improve the UX
> of device access.  I could imagine implementing this feature for use with
> Geolocation as well as notifications.  For example:
>
> interface Permissions {
>
> // permission values
> const unsigned long PERMISSION_ALLOWED = 0;
> const unsigned long PERMISSION_UNKNOWN = 1;
> const unsigned long PERMISSION_DENIED  = 2;
>
> void checkPermission(in DOMString type, in Function callback);
>
> }
>
> Then we could do something like:
>
> navigator.permissions.checkPermission("desktop-notification",
> function(value) {});
>
> or
>
> navigator.permissions.checkPermission("geolocation", function(value) {});
>
>
I like this idea, I think it's definitely preferable to a one-off permission
system just for notifications.

Your proposal doesn't have a way to explicitly request permission.  Would
you be willing to add that, with the recommendation that it only take place
on a user gesture?  I don't think this eliminates the ability to implement
request-on-first-use, if that's what Mozilla prefers, but I also still think
there is benefit to allowing permissions to be obtained separately from
invoking the API in question.

The bigger question is, are other features interested?  Would the
Geolocation spec consider using something like this for permissions?


> 2) Add language to the spec to indicate that the DOMStrings used
> |createNotification| are not to include any mark up.  Basically,
> implementations are going to hand off notifications to system-level
> services.  For example, on the Mac, GROWL does not handle any mark up...
> their API just takes plain strings.  I'd like to see the API reflect this
> reality.  Something like "the |title| and |body| arguments are to be treated
> as plain text"... or some such language.
>
>
Although the group isn't chartered to deliver the spec forward, FWIW I agree
with this suggestion (it was always the intent) and have made this language
explicit in the editor's draft.


>
> 3) Move Web notifications to a version 2 of the specification.  For the
> most basic use cases, this API isn't required and a web developer could use
> the more base API to simulate this.  Furthermore, as I mentioned above, many
> system-level notification services know nothing about rendering html.


Though I think web content still makes sense for notifications coming from a
web browser, and would want to publish an API which drives things in that
direction, I think this is reasonable if it will encourage greater
implementation of the basic API.  As long as the text+icon API we use
doesn't cut off that avenue, and I think what we have now meets that.

 -John

Thoughts on WebNotification

[Doug Turner]

I have been thinking a bit on Desktop Notifications [1].  After reviewing the 
Web Notification specification [2], I would like to propose the following 
changes:


1) Factor out the permission api into a new interface and/or spec.  The ability 
to test for a permission without bring up a UI would improve the UX of device 
access.  I could imagine implementing this feature for use with Geolocation as 
well as notifications.  For example:

interface Permissions {

// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED  = 2;

void checkPermission(in DOMString type, in Function callback);

}

Then we could do something like:

navigator.permissions.checkPermission("desktop-notification", function(value) 
{});

or

navigator.permissions.checkPermission("geolocation", function(value) {});



2) Add language to the spec to indicate that the DOMStrings used 
|createNotification| are not to include any mark up.  Basically, 
implementations are going to hand off notifications to system-level services.  
For example, on the Mac, GROWL does not handle any mark up... their API just 
takes plain strings.  I'd like to see the API reflect this reality.  Something 
like "the |title| and |body| arguments are to be treated as plain text"... or 
some such language.



3) Move Web notifications to a version 2 of the specification.  For the most 
basic use cases, this API isn't required and a web developer could use the more 
base API to simulate this.  Furthermore, as I mentioned above, many 
system-level notification services know nothing about rendering html.



I hope that this is helpful,
Doug Turner
Mozilla Corp


[1] http://dougt.org/wordpress/2010/06/desktop-notifications/
[2] http://dev.w3.org/2006/webapi/WebNotifications/publish/

Re: Bubbling/Capturing for XHR + other non-DOM objects

[Dmitry Titov]

I think you are answering your own question... The spec
says
:

"Each event flow must define how the propagation path shall be determined
> and which event phases are supported. The DOM event flow is an application
> of this model: the propagation path for a Node object shall be determined by
> its Node.parentNode chain, and if applicable, the document's containing
> defaultView; all events accomplish the capture and target phases; whether an
> event accomplishes the bubble phase shall be defined individually for each
> event type. An alternate application of this model can be found in [DOM3
> Load and Save]."


This sounds like the capture/target/bubble route is specifically defined for
Node object. XHR, FileReader, Workers or other objects are not Nodes and may
have their own 'event flows' defined, and it happened to be 'at_target' only
in most cases. The specs for those objects often describe the explicit event
flow.
If it doesn't or if the description is ambiguous, it probably should be
changed.

Dmitry

On Tue, Jun 22, 2010 at 4:53 PM, Travis Leithead wrote:

> Hi webapps and DOM events folks!
>
>
>
> (Cross-posting this)
>
>
>
> This topic came up internally on the IE team, and we thought it would be
> noteworthy to put this question before the working groups in hopes of
> getting a spec clarification made.
>
>
>
> The question is: for XHR and other non-DOM related objects that support the
> EventTarget interface, meaning objects that will be surfaced off of “window”
> but aren’t really a part of the markup tree, how should event propagation be
> handled?
>
>
>
> There is some good language in the current DOM Level 3 events spec,
> although in the context of this question it reads somewhat ambiguously.
> First, in section 3.1 Event dispatch and DOM event flow [1], the spec hints
> that any phase of the event flow may be skipped if it is “not supported”:
>
>
>
>A phase shall be skipped if it is not supported, or if the event
> object's propagation has been stopped.
>
>
>
> Then, later in the same section, the spec states that the model “defined
> above” _*must*_ be followed regardless of the specific event flow
> associated with the target. Naturally, the model is the
> capture-target-bubble phase, but the previous section also describes how the
> defaultView is handled in the propagation path:
>
>
>
>In the production of the propagation path, if the defaultView implements
> the EventTarget interface, the event propagates from defaultView to the
> document object during the capture phase, and from the document object to
> the defaultView during the bubble phase. Note: for legacy reasons, the load
> event does not propagate to the defaultView in HTML implementations.
>
>
>
> In browsers, the defaultView (window) does support the EventTarget
> interface.
>
>
>
> So given all of that background, one of the key questions for XHR is if an
> XHR instance belongs to a defaultView or not. One might ask the same thing
> of localStorage (though storage events fire on the window, not the Storage
> instance), indexDB, Workers, Notifications, FileAPI etc. where the API is
> not really related to the DOM tree (I’ll call these non-DOM objects).
>
>
>
> In each of these cases (or is it the same for all cases?) should we expect
> events to **capture** through the defaultView to the XHR (indexDB,
> FileAPI, etc.) instance, and then optionally bubble back to it, or are these
> objects just islands unto themselves, where there is only an **at_target**
> phase for events the fire on them?
>
>
>
> My recommendation: exempt these non-DOM objects from requiring strict
> adherence to the DOM event flow. In a simple test [2], I show that all major
> browsers (except Opera) fire ‘readystatechange’ directly on the XHR instance
> and *do not* capture the event through the window object (Opera did not
> appear to support addEventListener on the XHR instance when I tried).
>
>
>
> [1]
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-flow
>
> [2]
>
>
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
>
> http://www.w3.org/1999/xhtml"; >
>
> 
>
> Capture testing
>
> input[type="text"] { width: 400px; }
>
> 
>
> 
>
>   
>
>   function testXHR() {
>
>  window.xhrEventCaptures = false;
>
>  window.xhrEventTarget = false;
>
>
>
>  window.addEventListener('readystatechange', function () {
> window.xhrEventCaptures = true; }, true);
>
>  var xhr = new XMLHttpRequest();
>
>  xhr.addEventListener('readystatechange', function () {
> window.xhrEventTarget = true; }, true);
>
>  xhr.open("GET", "http://www.bing.com/";);
>
>  xhr.send();
>
>  setTimeout(function () {
>
>  document.querySelectorAll('in

ISSUE-117: In Widget P&C Spec, need to clarify in the spec that dir attribute does not apply to attributes that are IRIs, Numeric, Keywords, etc. The dir attribute only affects human readable strings.

[Web Applications Working Group Issue Tracker]

ISSUE-117: In Widget P&C Spec, need to clarify in the spec that dir attribute 
does not apply to attributes that are IRIs, Numeric, Keywords, etc. The dir 
attribute only affects human readable strings.

http://www.w3.org/2008/webapps/track/issues/117

Raised by: 
On product: 

Re: [IndexedDB] Computed indexes

[Jeremy Orlow]

On Thu, Jun 24, 2010 at 3:48 PM, Shawn Wilsher  wrote:

>  On 6/24/2010 7:01 AM, Jeremy Orlow wrote:
>
>> So what your proposing is that the keyPath would essentially be a string
>> of
>> the body of a function which runs for every index (on that objectStore)
>> for
>> every value inserted into that object store?  This seems like half way
>> between the eval-like idea I mentioned earlier.  It certainly seems to
>> have
>> advantages for complex keyPaths, but I'm still not so hot on having
>> boilerplate/assumptions (like needing "return" and assuming "value" is
>> present) present in every single keyPath.  Especially when the use cases
>> (while important) don't seem to be the common case.  (In fact, can you
>> even
>> do this in SQL?  If not, I think it's pretty strong evidence against
>> needing
>> to do arbitrary calculations in a keyPath.)
>>
> You can do something like this with triggers I think.
>

Triggers are actually a feature people within Google have asked me for.
 Such a thing would be useful for more than just computed indexes but would
likely be more heavyweight.  As far as I can tell, a trigger that fires on
changes to an objectStore would be enough to implement this feature
yourself.  We should probably look at general purpose triggers along side
these other keyPath proposals.


>
> Cheers,
>
> Shawn
>
>

Re: [IndexedDB] Computed indexes

[Shawn Wilsher]

 On 6/24/2010 7:01 AM, Jeremy Orlow wrote:

So what your proposing is that the keyPath would essentially be a string of
the body of a function which runs for every index (on that objectStore) for
every value inserted into that object store?  This seems like half way
between the eval-like idea I mentioned earlier.  It certainly seems to have
advantages for complex keyPaths, but I'm still not so hot on having
boilerplate/assumptions (like needing "return" and assuming "value" is
present) present in every single keyPath.  Especially when the use cases
(while important) don't seem to be the common case.  (In fact, can you even
do this in SQL?  If not, I think it's pretty strong evidence against needing
to do arbitrary calculations in a keyPath.)

You can do something like this with triggers I think.

Cheers,

Shawn



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [IndexedDB] Computed indexes

[Jeremy Orlow]

On Sat, Jun 19, 2010 at 9:05 AM, Jonas Sicking  wrote:

> On Fri, Jun 18, 2010 at 7:42 PM, Jeremy Orlow  wrote:
> > On Thu, Jun 17, 2010 at 3:25 PM, Jonas Sicking  wrote:
> >>
> >> Hi All,
> >>
> >> We've debated a bit use cases like storing objects like:
> >>
> >> { name: "Elvis", born: "January 8, 1935", died: "August 16, 1977" }
> >> { name: "Gustav III", born: "24 January 1746", died: "29 March 1792" }
> >>
> >> And create an index based on the age at time of death. Similarly,
> >> store HTML documents and index on the URLs of the outgoing links in
> >> the documents.
> >>
> >> The way to solve this use case in the current draft is by creating an
> >> index without a keyPath and then manually insert things into that
> >> index as needed. However this has some significant downsides:
> >>
> >> * First of all it's more manual labor for the author to everywhere
> >> where an entry is added also add things to the index.
> >> * It's a bit unclear who is responsible for removing things from the
> >> index. The spec currently says that it's forbidden to add things to
> >> the index which doesn't have a corresponding entry in the objectStore,
> >> however it doesn't forbid removing an entry from the objectStore which
> >> has entries in the index pointing to it. But it also doesn't say that
> >> entries in the index are automatically removed when an entry in the
> >> objectStore is removed.
> >> * If the author is responsible for removing things from the index,
> >> then this could mean having to compute all the index values both on
> >> insertion and on removal into the objectStore.
> >> * Unless the author is prepared to add a lot of logic to his code, it
> >> means that all indexes have to be immediately updated whenever an
> >> insertion/removal takes place. This can be very suboptimal if the
> >> objectStore is modified several times between accesses to a given
> >> index. Compare this to indexes that use a keyPath where the
> >> implementation could lazily only insert things into an index when the
> >> index is accessed.
> >> * It requires all code that inserts and modifies an objectStore to be
> >> aware of all the keyPath-less indexes attached to the objectStore and
> >> how to update them.
> >
> > You missed one: if your index is non-unique, then the only way to update
> it
> > is by using a cursor...which is even more async calls for every update
> > and/or much more complicated logic to batch them up.
>
> Indeed.
>
> >> We have talked about two solutions to this problem so far:
> >>
> >> Upon calls to .add/.put/.update can require that the author passes in
> >> lists of values which are to be used as keys in the various indexes
> >> that are attached to the objectStore. This solves some of the problems
> >> mentioned above, but most of them are not addressed.
> >
> > Which ones are not addressed?  I'm not sure I agree.
>
> The following ones would seem to still apply:
>
> * First of all it's more manual labor for the author to everywhere
> where an entry is added also add things to the index.
> (Though the labor is significantly simpler and should result in much less
> code)
>

Agreed, assuming you can do everything with keyPath that you could do
manually with this implementation.


> * Unless the author is prepared to add a lot of logic to his code, it
> means that all indexes have to be immediately updated whenever an
> insertion/removal takes place. This can be very suboptimal if the
> objectStore is modified several times between accesses to a given
> index. Compare this to indexes that use a keyPath where the
> implementation could lazily only insert things into an index when the
> index is accessed.
> (actually, this one applies even more as it is impossible to comput
> the index values lazily as the have to be supplied on
> insertion/update)
>

I agree, though I think we have _much_ bigger fish to fry for v1.  Enough
so, that I'd actually like to see some hard examples of where updating the
indexes really becomes a performance concern.  My guess is that by the time
we add new features and tune what we have in IndexedDB to the point that
this becomes a concern, things will have changed enough that we'll have
different ideas on how best to optimize this case.  I feel pretty strongly
that we should not worry about this for now.


> * It requires all code that inserts and modifies an objectStore to be
> aware of all the keyPath-less indexes attached to the objectStore and
> how to update them.
>

This is definitely unfortunate.


>> We could allow a more complex expression to be used which would be
> >> evaluated for each entry in the objectStore and which produce the set
> >> of keys to be used for that index. This solves all the problems
> >> mentioned above, but has some problems of its own. In particular:
> >>
> >> 1. We can't allow a JS function to be passed in as that would pull in
> >> all the scope of that function which generally has a lifetime much
> >> shorter than the index. Thus we wo

[Bug 10007] New: Async callbacks should fire in the same order the async requests are made in IndexedDB.

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10007

   Summary: Async callbacks should fire in the same order the
async requests are made in IndexedDB.
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: nikunj.me...@oracle.com
ReportedBy: jor...@chromium.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org, jo...@sicking.cc


Per the "[IndexedDB] Callback order" thread [1], we should specify the order of
async callbacks (either onsuccess or onerror) to fire in the order that the
async requests are made.  I.e. the same order the IDBRequest objects are
returned.

[1] http://www.mail-archive.com/public-webapps@w3.org/msg09208.html

-- 
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] Callback order

[Jeremy Orlow]

On Sat, Jun 19, 2010 at 9:12 AM, Jonas Sicking  wrote:

> On Fri, Jun 18, 2010 at 7:46 PM, Jeremy Orlow  wrote:
> > On Fri, Jun 18, 2010 at 7:24 PM, Jonas Sicking  wrote:
> >>
> >> On Fri, Jun 18, 2010 at 7:01 PM, Jeremy Orlow 
> wrote:
> >> > I think determinism is most important for the reasons you cited.  I
> >> > think
> >> > advanced, performance concerned apps could deal with either semantics
> >> > you
> >> > mentioned, so the key would be to pick whatever is best for the normal
> >> > case.
> >> >  I'm leaning towards thinking firing in order is the best way to go
> >> > because
> >> > it's the most intuitive/easiest to understand, but I don't feel
> strongly
> >> > about anything other than being deterministic.
> >>
> >> I definitely agree that firing in request order is the simplest, both
> >> from an implementation and usage point of view. However my concern is
> >> that we'd lose most of the performance benefits that cursors provide
> >> if we use that solution.
> >>
> >> What do you mean with "apps could deal with either semantics"? You
> >> mean that they could deal with the cursor case by simply being slower,
> >> or do you mean that they could work around the performance hit
> >> somehow?
> >
> > Hm.  I was thinking they could save the value, call continue, then do
> work
> > on it, but that'd of course only defer the slowdown for one iteration.
>  So I
> > guess they'd have to store up a bunch of data and then make calls on it.
>
> Indeed which could be bad for memory footprint.
>
> > Of course, they'll run into all of these same issues with the sync API
> since
> > things are of course done in order.  So maybe trying to optimize this
> > specific case for just the async API is silly?
>
> I honestly haven't looked at the sync API. But yes, I assume that it
> will in general have to serialize all calls into the database and thus
> generally not be as performant. I don't think that is a good reason to
> make the async API slower too though.
>
> But it's entirely possible that I'm overly concerned about cursor
> performance in general though. I won't argue too strongly that we need
> to prioritize cursor callback events until I've seen some numbers. If
> we want to simply define that callbacks fire in request order for now
> then that is fine with me.
>

Yeah, I think we should get some hard numbers and think carefully about this
before we make things even more complicated/nuanced.

J

Re: [IndexedDB] Atomic schema changes

[Jeremy Orlow]

On Thu, Jun 24, 2010 at 1:48 AM, Jonas Sicking  wrote:

> Hi All,
>
> In bug 9975 comment 1 [1] Nikunj pointed out that it is unclear how to
> make atomic changes to the schema of a database. For example adding an
> objectStore and a couple of indexes.
>
> While it actually currently is possible, it is quite quirky and so I
> think we need to find a better solution.
>
> One way this is already possible is by calling setVersion. When the
> success event fires for this request, it contains an implicitly
> created transaction which, while it is alive, holds a lock on the
> whole database an prevents any other interactions with the database.
>
> However setVersion is a fairly heavy operation. We have discussed a
> couple of different ways it can work, but it seems like there is
> agreement that any other open database connections will either have to
> be close manually (by for example the user leaving the page), or they
> will be close forcefully (by making any requests on them fail). I
> intend on sending a starting a separate thread on defining the details
> of setVersion.
>
> We might want to allow making smaller schema changes, such as adding a
> new objectStore or a new index, without requiring all other database
> connections to be closed. Further, it would be nice if "atomicness"
> was a default behavior as to avoid people accidentally creating race
> conditions.
>
> We've talked a bit about this at mozilla and have three alternative
> proposals. In all three proposals we suggest moving the
> createObjectStore to the Transaction interface (or possibly a new
> SchemaTransaction interface). The createIndex function remains on
> objectStore, but is defined to throw an exception if called outside a
> transaction which allows schema changes.
>
> Proposal A:
> Always require calls to setVersion for changes to the database schema.
> The success event fired on the setVersion request is a
> IDBTransactionEvent. The author can use the createObjectStore method
> on the transaction available on the event to create new object stores.
>
> Additionally, since we know that no one else currently has an open
> database connection, we can make creating objectStores synchronous.
> The implementation can probably still asynchronously fail to create an
> objectStore, due to diskspace or other hardware issues. This failure
> will likely only be detected asynchronously, but can be raised as a
> failure to commit the transaction as it is extremely rare.
>
> The code would look something like:
>
> if (db.version == "2.0") {
>  weAreDoneFunction();
> }
> db.setVersion("2.0").onsuccess = function(event) {
>  trans = event.transaction;
>  store1 = trans.createObjectStore("myStore1", ...);
>  store2 = trans.createObjectStore("myStore2", ...);
>  store1.createIndex(...);
>  store1.createIndex(...);
>  store2.createIndex(...);
>  trans.oncomplete = weAreDoneFunction;
> }
>
> Proposal B:
> Add a new type of transaction SCHEMA_CHANGE, in addition to READ and
> READ_WRITE. This transaction is required for any schema changes. As
> long as the transaction is open, no other schema changes can be done.
> The transaction is opened asynchronously using a new
> 'startSchemaTransaction' function. This ensures that no other
> modifications are attempted at the same time.
>
> Additionally, since we know that no one else currently is inside a
> SCHEMA_CHANGE transaction we can make creating objectStores
> synchronous. The implementation can probably still asynchronously fail
> to create an objectStore, due to diskspace or other hardware issues.
> This failure will likely only be detected asynchronously, but can be
> raised as a failure to commit the transaction as it is extremely rare.
>
> Code example:
>
> if (db.objectStoreNames.contains("myStore1")) {
>  weAreDoneFunction();
>  return;
> }
> db.startSchemaTransaction().onsuccess = function(event) {
>  // Have to check again as the objectStore could have been created
> before the callback fired
>  if (db.objectStoreNames.contains("myStore1")) {
>weAreDoneFunction();
>return;
>  }
>  trans = event.transaction;
>  store1 = trans.createObjectStore("myStore1", ...);
>  store2 = trans.createObjectStore("myStore2", ...);
>  store1.createIndex(...);
>  store1.createIndex(...);
>  store2.createIndex(...);
>  trans.oncomplete = weAreDoneFunction;
> }
>
>
> Proposal C:
> This is like proposal B, however the schema change transaction is
> started synchronously, same as other transactions (we could even reuse
> the existing transaction() function, however we'd have to ignore the
> storeNames argument).
>
> Since two different pages, running in different processes, could now
> start a schema-change transaction at the same time, and thus could
> call createObjectStore at the same time and attempt to create the same
> store, we have to keep createObjectStore asynchronous.
>
> Code example:
>
> if (db.objectStoreNames.contains("myStore1")) {
>  weAreDoneFunction();
>  return;
> }
> trans = db.startSchema