Many of these points I have no response to and would like to hear
Ian's take.
For some points, I have answers based on my current understanding...
On Feb 25, 2008, at 12:56 PM, Ralf Stoltze wrote:
- In 4.3.2, the spec defines the concept of origin, with respect to
script elements. However, the term is also used in combination with
browsing contexts and databases. 4.11.2 says: "Each origin has an
associated set of databases."
So what is the origin of a database?
- the originating host of the script which creates a database?
- the origin of the document that script belongs to?
...
- cont'd:
"this database feature is limited to scripts running with the same
origin as the database."
Seems like my English is too limited here. What does "running with"
mean?
- the originating host of the script?
- the origin of the document that script belongs to?
Again, this comes down to defining the origin of a database.
We've had the assumption that the origin is with the associated
browsing context, and therefore the document the script belongs to.
Clarification would be great...
- 4.11.3 defines that placeholders simply have to be replaced with
values from the arguments array. As I understand, this does not per se
ban SQL injections. Will the spec define *how* to replace
placeholders,
including how to escape and quote values?
Placeholders are the mechanism the spec mandates to prevent SQL
injections et al. *How* seems to be an implementation detail.
SQLite, for example, has the ? + argument structure in place already.
- From 4.11.3:
"A mostly arbitrary limit of five megabytes per origin is
recommended."
The session/local storage part defines a quota on a per domain
basis. Is
there any reason for this inconsistency (since both specs are now
based
on the origin model)? Circumventing origin restrictions with
subdomains
is the same for local storage and database storage.
I believe Ian had an explanation for this when it was raised earlier
on this list, but can't remember what it was. :) Would like to hear
it again.
- I've seen some discussion on this list regarding the order of
execution of statements within one transaction. However, I believe
that
this was related to an older version of the spec (which had implicit
transactions?).
Based on 4.11.6, step 6.7, I assume the following snippet to always
execute in order 1, 2, 3?
db.transaction(function(tx) {
tx.executeSql('query 1', null, function(tx, rs) {
tx.executeSql('query 2', null, function(tx, rs) {
});
});
tx.executeSql('query 3', null, function(tx, rs) {
});
});
4.11.3 step 6 states that if an executeSql call passed steps 1-5, the
statement is queued up in the transaction.
4.11.6 step 6.7 says "move on to the next statement, if any"
I trust this means "the next statement in the transaction's statement
queue" and that the queue pops statements in the order they were queued.
This means that query 1 would be queued, query 3 would be queued, then
in the callback for query 1, query 2 would be queued.
Execution order 1, 3, 2
If a javascript engine was truly interruptible, query 1 completed
before query 3 was queued, and the engine for some reason decided to
run the query 1 callback before query 3 was scheduled, the order would
end up 1, 2, 3 - but I don't see that happening with any current JS
implementation, and I don't know what ECMAScript 4 says about the
future of JS in this regard.
~Brady
