Re: [IndexedDB] Atomic schema changes
On Fri, Jun 25, 2010 at 2:43 AM, Jeremy Orlow jor...@chromium.org wrote:
I'm OK with making createObjectStore/createIndex synchronous. It would
definitely make such code cleaner and I don't see a major downside, but
at
the same time I feel like this API is starting to get kind of ad-hoc and
unintuitive to a new user. Having the create and the remove functions
completely different and in different places seems weird.
So I agree with either A or leaving things as originally proposed by
Jonas
in [IndexDB] Proposal for async API changes.
Well, there's no reason not to make the same changes to
removeObjectStore/removeIndex. Though the more I think with this
design createObjectStore and removeObjectStore can stay on IDBDatabase
and simply throw if called outside the appropriate transaction
callback.
Here is the revised proposal:
interface IDBDatabase {
...
IDBObjectStore createObjectStore (in DOMString name, in optional
DOMString keyPath, in optional boolean autoIncrement);
void removeObjectStore (in DOMString storeName);
...
};
interface IDBObjectStore {
...
IDBIndex createIndex (in DOMString name, in DOMString keyPath, in
optional boolean unique);
IDBRequest removeIndex (in DOMString indexName);
...
};
Where createObjecStore/createIndex throws if a objectStore or index of
the given name already exists, if the keyPath has an invalid syntax,
or if the function is called when not inside a version-change
transaction callback. And removeObjectStore/removeIndex throws if the
objectStore or index doesn't exist or if the function is called when
not inside a version-change transaction callback.
Throwing if not inside the right type of callback isn't a super clean
solution, but is really not that different from how add/put throws if
called when not inside a READ_WRITE transaction.
Just to be clear, no async function (one that returns an IDBRequest) should
_ever_ throw. (They should only call onerror.) I assume you didn't mean
add/put throws literally?
Well, there's no reason we couldn't make add/put throw if called from
inside the wrong type of transaction. I guess I don't feel strongly
about it, but it seems to me that calling put from inside a READ_ONLY
transaction is a much bigger mistake than writing a duplicate key or
running out of disc space. Additionally it's a situation where we
synchronously know that there is a bug in the program.
But, I feel pretty strongly that a setVersion/schema change transaction
should not simply kill off anything else currently running. The reason
is
that it's not hard for apps to recover from a connection failing, but it
is
hard to handle a transaction failing in an unpredictable way.
Especially
static transactions (which should rarely fail committing since
serialization
can be guaranteed before the transaction starts).
That might be a good idea for v1. I was planning on doing a separate
thread for setVersion, but maybe it's tied enough to the topic of
schema changes that it makes sense to bring up here.
What I suggest is that when setVersion is called, we fire
'versionchange' event on all other open IDBDatabase objects. This
event contains information of what the desired new version number is.
If no other IDBDatabase objects are open for the specific database, no
'versionchange' events are fired. This allows pages using the old
schema version to automatically save any pending data (for example any
draft emails) and display UI to the user suggesting that the tab be
closed. If possible without dataloss, the tab could even reload itself
to automatically load an updated version of the page which uses the
new schema version.
The 'versionchange' event would use an interface like
interface IDBVersionEvent : IDBEvent {
readonly attribute string version;
};
First of all, what I was originally advocating (sorry for not being clear)
is that we should kill the database connection but not until all active
transactions are complete. Though we should probably block new transactions
from starting once setVersion is called.
But I really like your versionchange event idea regardless. I agree that
letting the app sync any data that might be in memory (for example, a draft
email) is important. And the idea that the web app could refresh itself (or
download new application code or something) seems pretty cool and useful.
I'm fine with it firing on all frames except the one that initiated (like
storage events). If we go with the kill the connection once all active
transactions are done and block new ones from starting, we'd want to start
the blocking only after all versionchange events have finished.
The main reason that I like the idea of not stating the version change until
all active connections have closed is that not all apps will handle
versionchange. My original idea was that we should just break such web apps
and let the user refresh, but now
Re: [IndexedDB] IDBEvent and Event
On Fri, Jun 25, 2010 at 2:20 PM, Shawn Wilsher sdwi...@mozilla.com wrote: Hey all, I think that IDBEvent needs to inherit from Event [1] in order for us to properly inherit from EventTarget in IDBRequest. Specifically, EventTarget takes an EventListener [2] which has a method, handleEvent, that takes an Event object. I'm not sure this makes sense for us though, so I figured I'd start a discussion before filing the bug. Cheers, Shawn [1] http://www.w3.org/TR/DOM-Level-3-Events/#interface-Event [2] http://www.w3.org/TR/DOM-Level-3-Events/#interface-EventListener Technically I don't think inheriting from Event is required. You can generally always use language specific means of casting between interfaces. This is how for example Document [1] and DocumentTraversal [2] are related. I.e. even though you receive an Event object in handleEvent, you can always cast that to IDBEvent using whatever casting mechanism your language have. However if we want to follow the pattern used everywhere else for events [3], and I definitely think we do, then IDBEvent should indeed inherit from Event. In javascript it makes no difference as all properties from all interfaces should be directly available without any explicit casting needed. For example a div returned from getElementById [4] has the functions from both Element [5] and ElementCSSInlineStyle [6] immediately available, even though getElementById returns an Element interface. [1] http://www.w3.org/TR/DOM-Level-3-Core/core.html#i-Document [2] http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html#Traversal-Document [3] http://www.w3.org/TR/DOM-Level-3-Events/ [4] http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-getElBId [5] http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-745549614 [6] http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-ElementCSSInlineStyle / Jonas
Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 5:34 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jun 24, 2010 at 7:38 PM, Doug Turner doug.tur...@gmail.com 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.
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 happy with this course of action, but first I wanted to ask why not the
gracefully degrade suggestion from the Notifications thread started on
the 3rd of Feb. As far as I can tell, it was never seriously considered,
but several of us brought it up. And I feel like it'd be a much better way
forward than having a different interface for html based notifications and
text notifications.
(The basic idea was to accept either text or html and then if it's the
latter and the notification scheme doesn't support it, we'd use some simple,
specced heuristics to extract data to be used. In the thread, there were
some specific ideas about how the transformations could work. But from a
quick skim, I couldn't find any reasons why it was a bad idea.)
I think history has showed that optional features generally work
pretty poorly. While there are decent heuristics available to extract
textual data from html, I doubt that they'll be good enough. For
example I suspect that people will send notifications like:
You've got mail. Click a href=...here/a to read it
img src='...'
Would you like to take our survey?form ...input name=answer
type=submit value=yesinput name=answer type=submit value=no/form
/ Jonas
Re: [IndexedDB] Computed indexes
On Thu, Jun 24, 2010 at 7:01 AM, Jeremy Orlow jor...@chromium.org wrote:
4. Maciej expressed concern that this might make it impossible to
expose IndexedDB to non-JS languages such as ObjectiveC
Let me address these in order (for the purposes of this discussion
I'll use a separate function to create one of these indexes called
createExpressionIndex. I'd prefer to do the bike-shedding afterward if
possible):
While I think 1 is unfortunate, i don't think it's a big deal.
Fortunately Javascript has the nice feature that it allows functions
to be serialized into strings, which means that while you can't do
myObjectStore.createExpressionIndex(myIndex, function(val) { return
});
you can do
myObjectStore.createExpressionIndex(myIndex, (function(val) { return
}).toString());
Do most JS engines allow _any_ function to be stored away for later?
If you mean if _any_ function can be serialized using toString(), then
yes, I believe so. Though of course serializing loses all scope
references so it's not guaranteed to work. And non-builtin functions.
Functions like Array.sort or Document.getElementById can of course not
be serialized.
This may be true of JavaScript and even many other interpreted languages,
but it's not true of many (most?) compiled languages. How would we handle
this in the spec? Would we say it's unsupported in v1 or say that such
implementations would define their own language (or use an existing
interpreted language) as they see fit? I guess this isn't a deal breaker
since JavaScript really is the main target for this, but it's somewhat
unfortunate.
Like I said in an earlier email in this thread, we can fairly easily
solve this using WebIDL. All that we really need here is a callback
which can be called after browser restarts. Javascript doesn't provide
any such means, which is why we have to resort to passing in a string.
However in for example Java I believe you could provide enough
information that the IndexedDB implementation can find the proper
class and function even after application restart.
However what I really think is the important question here is if the
people that expressed concern about tying to javascript in the past
are concerned about the more specific technical proposals that have
been made since then.
What is the difference between an expressionIndex and a keyPath? It
seems
like they're doing about the same thing. My proposal to allow keyPath
to be
artibrary JavaScript and then have the value being inserted be the
global
scope actually sounds almost identical to what you're doingexcept
more
in the relm of what JS engines already do (since it's much like an
eval).
It is about the same thing yes. Though presumably an implementation
could optimize evaluating the keyPath heavily. Much more so than a
generic expression.
Howso? Any implementation should be able to cache the compiled/JITed form
of the string passed into it's internal implementation of eval.
Executing a complied expression, including firing up all the contexts
needed to run a piece of javascript, is at least in the firefox js
engine, significantly more expensive than simply grabbing the relevant
value as you serialize the javascript object into the database.
Additionally, for a simple keyPath you don't have to worry about
cloning objects or implementing copy-on-write semantics.
Finally, you can perform optimizations such as not updating indexes if
you notice that the relevant property doesn't change during calls to
objectStore.put() and cursor.update().
All in all I think keyPaths are preferrable when they are possible.
Full on expressions will likely always be slower and more cumbersome,
but they seem better than the alternatives when the value isn't stored
directly in the stored object.
Allowing keyPath to be an arbitrary expression turns out to result in
weird edge cases once you define all details. Say that you're storing
the value:
{ foo: 5, bar: 10 }
You want to evaluate the expression in a context where foo and bar
are in scope. But you also don't want to evaluate with the value as
the global object as then a = 5 would modify the value as that sets
a global variable. I.e. something like t = foo*foo; bar + t; would
add a 't' property to value. And you also don't want to evaluate the
expression in a context where the value is the current scope as then
var a = 5 would modify the value.
Additionally, you have to define what value is returned. We could do
like 'eval' is doing and say that the last evaluated expression is
what is returned. However eval doesn't let you return early using the
'return' statement which might be practical.
These problems could possibly be overcome though. I'll have to check
with people that know JS better than me. Ideas welcome.
You're right that simply making it the global scope won't work unless we
make a copy of it the global scope or do copy-on-write. The
Re: Thoughts on WebNotification
On Sat, Jun 26, 2010 at 10:47 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 25, 2010 at 5:34 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jun 24, 2010 at 7:38 PM, Doug Turner doug.tur...@gmail.com
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.
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 happy with this course of action, but first I wanted to ask why not
the
gracefully degrade suggestion from the Notifications thread started
on
the 3rd of Feb. As far as I can tell, it was never seriously considered,
but several of us brought it up. And I feel like it'd be a much better
way
forward than having a different interface for html based notifications
and
text notifications.
(The basic idea was to accept either text or html and then if it's the
latter and the notification scheme doesn't support it, we'd use some
simple,
specced heuristics to extract data to be used. In the thread, there were
some specific ideas about how the transformations could work. But from a
quick skim, I couldn't find any reasons why it was a bad idea.)
I think history has showed that optional features generally work
pretty poorly. While there are decent heuristics available to extract
textual data from html, I doubt that they'll be good enough. For
example I suspect that people will send notifications like:
You've got mail. Click a href=...here/a to read it
img src='...'
Would you like to take our survey?form ...input name=answer
type=submit value=yesinput name=answer type=submit value=no/form
Which proposal are you in favor of then? Your first paragraph seems to
agree with me and your second (which is fairly compelling) seems to
disagree.
J
Re: [IndexedDB] Computed indexes
On Sat, Jun 26, 2010 at 12:11 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 24, 2010 at 7:01 AM, Jeremy Orlow jor...@chromium.org wrote:
4. Maciej expressed concern that this might make it impossible to
expose IndexedDB to non-JS languages such as ObjectiveC
Let me address these in order (for the purposes of this discussion
I'll use a separate function to create one of these indexes called
createExpressionIndex. I'd prefer to do the bike-shedding afterward
if
possible):
While I think 1 is unfortunate, i don't think it's a big deal.
Fortunately Javascript has the nice feature that it allows functions
to be serialized into strings, which means that while you can't do
myObjectStore.createExpressionIndex(myIndex, function(val) { return
});
you can do
myObjectStore.createExpressionIndex(myIndex, (function(val) {
return
}).toString());
Do most JS engines allow _any_ function to be stored away for later?
If you mean if _any_ function can be serialized using toString(), then
yes, I believe so. Though of course serializing loses all scope
references so it's not guaranteed to work. And non-builtin functions.
Functions like Array.sort or Document.getElementById can of course not
be serialized.
This may be true of JavaScript and even many other interpreted languages,
but it's not true of many (most?) compiled languages. How would we
handle
this in the spec? Would we say it's unsupported in v1 or say that such
implementations would define their own language (or use an existing
interpreted language) as they see fit? I guess this isn't a deal breaker
since JavaScript really is the main target for this, but it's somewhat
unfortunate.
Like I said in an earlier email in this thread, we can fairly easily
solve this using WebIDL. All that we really need here is a callback
which can be called after browser restarts. Javascript doesn't provide
any such means, which is why we have to resort to passing in a string.
However in for example Java I believe you could provide enough
information that the IndexedDB implementation can find the proper
class and function even after application restart.
How would you do that in C/C++ though? As far as I know, Java is one of the
few languages where this is actually true. And even then it seems a bit
clunky. In C/C++, passing in a function pointer would not work once you
re-compile the program.
However what I really think is the important question here is if the
people that expressed concern about tying to javascript in the past
are concerned about the more specific technical proposals that have
been made since then.
I'm not sure if people who could make such an objection are watching these
threads very carefully (if at all), so I think we'll need to be more
proactive if we really want to get their advice. (i.e. at the very least,
start a new, specific thread on this topic with an obvious subject.)
What is the difference between an expressionIndex and a keyPath? It
seems
like they're doing about the same thing. My proposal to allow keyPath
to be
artibrary JavaScript and then have the value being inserted be the
global
scope actually sounds almost identical to what you're doingexcept
more
in the relm of what JS engines already do (since it's much like an
eval).
It is about the same thing yes. Though presumably an implementation
could optimize evaluating the keyPath heavily. Much more so than a
generic expression.
Howso? Any implementation should be able to cache the compiled/JITed
form
of the string passed into it's internal implementation of eval.
Executing a complied expression, including firing up all the contexts
needed to run a piece of javascript, is at least in the firefox js
engine, significantly more expensive than simply grabbing the relevant
value as you serialize the javascript object into the database.
Additionally, for a simple keyPath you don't have to worry about
cloning objects or implementing copy-on-write semantics.
Finally, you can perform optimizations such as not updating indexes if
you notice that the relevant property doesn't change during calls to
objectStore.put() and cursor.update().
All in all I think keyPaths are preferrable when they are possible.
Full on expressions will likely always be slower and more cumbersome,
but they seem better than the alternatives when the value isn't stored
directly in the stored object.
Ahh! I think I see why we're both having so hard of a time understanding
each other. I've been talking about various proposals for what keyPath
would be and you're talking about a proposal that'd be in addition to some
simple keyPath proposal (that could easily have the properties you just
mentioned above). That explains a lot.
I definitely like the idea of some simple keyPath concept optionally
augmented by a more complex one that can actually
Re: [IndexedDB] Atomic schema changes
On Sat, Jun 26, 2010 at 10:09 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 25, 2010 at 2:43 AM, Jeremy Orlow jor...@chromium.org wrote:
I'm OK with making createObjectStore/createIndex synchronous. It
would
definitely make such code cleaner and I don't see a major downside,
but
at
the same time I feel like this API is starting to get kind of ad-hoc
and
unintuitive to a new user. Having the create and the remove functions
completely different and in different places seems weird.
So I agree with either A or leaving things as originally proposed by
Jonas
in [IndexDB] Proposal for async API changes.
Well, there's no reason not to make the same changes to
removeObjectStore/removeIndex. Though the more I think with this
design createObjectStore and removeObjectStore can stay on IDBDatabase
and simply throw if called outside the appropriate transaction
callback.
Here is the revised proposal:
interface IDBDatabase {
...
IDBObjectStore createObjectStore (in DOMString name, in optional
DOMString keyPath, in optional boolean autoIncrement);
void removeObjectStore (in DOMString storeName);
...
};
interface IDBObjectStore {
...
IDBIndex createIndex (in DOMString name, in DOMString keyPath, in
optional boolean unique);
IDBRequest removeIndex (in DOMString indexName);
...
};
Where createObjecStore/createIndex throws if a objectStore or index of
the given name already exists, if the keyPath has an invalid syntax,
or if the function is called when not inside a version-change
transaction callback. And removeObjectStore/removeIndex throws if the
objectStore or index doesn't exist or if the function is called when
not inside a version-change transaction callback.
Throwing if not inside the right type of callback isn't a super clean
solution, but is really not that different from how add/put throws if
called when not inside a READ_WRITE transaction.
Just to be clear, no async function (one that returns an IDBRequest)
should
_ever_ throw. (They should only call onerror.) I assume you didn't mean
add/put throws literally?
Well, there's no reason we couldn't make add/put throw if called from
inside the wrong type of transaction. I guess I don't feel strongly
about it, but it seems to me that calling put from inside a READ_ONLY
transaction is a much bigger mistake than writing a duplicate key or
running out of disc space. Additionally it's a situation where we
synchronously know that there is a bug in the program.
When this came up before, the thought was that it'd be confusing to web
developers which errors would raise immediately and which would call the
error callback. My feeling is that consistency is more useful than raising
right away for errors like this. (Plus, if we find it hard to get web
developers to do any error checking, it seems even harder to get them to do
it in 2 ways. :-)
But, I feel pretty strongly that a setVersion/schema change
transaction
should not simply kill off anything else currently running. The
reason
is
that it's not hard for apps to recover from a connection failing, but
it
is
hard to handle a transaction failing in an unpredictable way.
Especially
static transactions (which should rarely fail committing since
serialization
can be guaranteed before the transaction starts).
That might be a good idea for v1. I was planning on doing a separate
thread for setVersion, but maybe it's tied enough to the topic of
schema changes that it makes sense to bring up here.
What I suggest is that when setVersion is called, we fire
'versionchange' event on all other open IDBDatabase objects. This
event contains information of what the desired new version number is.
If no other IDBDatabase objects are open for the specific database, no
'versionchange' events are fired. This allows pages using the old
schema version to automatically save any pending data (for example any
draft emails) and display UI to the user suggesting that the tab be
closed. If possible without dataloss, the tab could even reload itself
to automatically load an updated version of the page which uses the
new schema version.
The 'versionchange' event would use an interface like
interface IDBVersionEvent : IDBEvent {
readonly attribute string version;
};
First of all, what I was originally advocating (sorry for not being
clear)
is that we should kill the database connection but not until all active
transactions are complete. Though we should probably block new
transactions
from starting once setVersion is called.
But I really like your versionchange event idea regardless. I agree that
letting the app sync any data that might be in memory (for example, a
draft
email) is important. And the idea that the web app could refresh itself
(or
download new application code or something) seems pretty
[Bug 9790] Request is not a good suffix for all the async interfaces in IndexedDB
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9790 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #2 from Nikunj Mehta nikunj.me...@oracle.com 2010-06-26 23:59:54 --- Because all the abstract interfaces were removed, it was necessary to correct NoInterfaceObject modifiers on IDBObjectStore, IDBCursor, IDBObjectStoreSync, and IDBCursorSync -- 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.
