Timothy Hatcher | 1 Nov 01:13 2007
Picon

Re: SQL API complex for simple cases

On Oct 31, 2007, at 4:56 PM, Ian Hickson wrote:

The fear is that people would do:

  db.executeSql('...', [], function(...) {
    db.executeSql('...', []); // depends on the first call
  });

...without a transaction.

How is that wrong? If the first executeSql fails the error callback (if any) will fire, not the normal callback.

  db.executeSql('CREATE TABLE ...', [], function(...) {
    db.executeSql('INSERT INTO ...', []);
  });

If the CREATE TABLE fails, the insert will never happen. If the INSERT fails, you don't really want the table to be rolled out. If you did, then you want a transaction. There are clearly times where you don't always want a transaction, but want to chain statements.

— Timothy Hatcher


Ian Hickson | 1 Nov 01:20 2007
Picon

Re: SQL API and Transactions

On Wed, 31 Oct 2007, Scott Hess wrote:
> On Oct 26, 2007 3:51 PM, Ian Hickson <ian@...> wrote:
> > On Thu, 25 Oct 2007, Brady Eidson wrote:
> > >
> > > Step 9 of the transaction steps stipulates that if the transaction 
> > > fails to commit, the script will get an SQLTransactionErrorCallback 
> > > indicating this failure.  However, there is no final callback 
> > > indicating *success* of the commit.
> 
> I agree with Brady, in many cases it will be essential to know that the 
> transaction has completed successfully.  On the other hand, the system 
> is starting to have sort of a lot of callbacks!  But if it's going to be 
> async, that's sort of the penalty to be paid.

Ok. Done.

> One option would be to change SQLTransactionErrorCallback to 
> SQLTransactionCompletionCallback.  Having a separate callback is 
> probably better if the success-handler always looks materially different 
> from the failure-handler, but I think it's possible that having a single 
> callback with an if() inside might be less confusing than two callbacks.

I'm not sure that's really any better, and it has the problem that you can 
no longer use a single common error handler.

> I think one could work around this within the current spec something 
> like:
> 
> var success = true;
> 
> db.transaction(function (t) {
>   t.executeSql('insert into x values (?)', [y]);
>   db.transaction(function (t) {
>     if (success) {
>       // This should be called after the outer transaction has completed.
>     }
>   }
> }, function (e) {
>   success = false;
> });
> 
> That's awful cumbersome, but if the need is seldom enough, it might be 
> reasonable.

Actually that wouldn't work because nested transactions are completely 
independent of the initial one, so unless the transaction blocked the 
entire database, the nested one above would finish immediately.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Ian Hickson | 1 Nov 01:22 2007
Picon

Re: executeSql without arguments

On Wed, 31 Oct 2007, Timothy Hatcher wrote:
>
> I think the spec should have a forth variant of executeSql that takes no 
> arguments argument.
> 
> void executeSql(in DOMString sqlStatement);
> 
> The JavaScript language makes it easy to pass in an empty array, but for 
> simplicity and the benefit of other language bindings this argument 
> should be optional.
> 
> That will keep basic select and create table statements simple.
> 
> tx.executeSql("CREATE TABLE WebKitStickyNotes (id REAL UNIQUE, note 
> TEXT, timestamp REAL, left TEXT, top TEXT, zindex REAL)");

Added.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Ian Hickson | 1 Nov 01:21 2007
Picon

Re: SQL API complex for simple cases

On Wed, 31 Oct 2007, Timothy Hatcher wrote:
> 
> How is that wrong? If the first executeSql fails the error callback (if 
> any) will fire, not the normal callback.
> 
>   db.executeSql('CREATE TABLE ...', [], function(...) {
>     db.executeSql('INSERT INTO ...', []);
>   });
> 
> If the CREATE TABLE fails, the insert will never happen. If the INSERT 
> fails, you don't really want the table to be rolled out. If you did, 
> then you want a transaction. There are clearly times where you don't 
> always want a transaction, but want to chain statements.

What if another page dropped the table between the CREATE and the INSERT?

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Scott Hess | 1 Nov 01:32 2007
Picon

Re: SQL API complex for simple cases

On Oct 31, 2007 5:21 PM, Ian Hickson <ian@...> wrote:
> On Wed, 31 Oct 2007, Timothy Hatcher wrote:
> > How is that wrong? If the first executeSql fails the error callback (if
> > any) will fire, not the normal callback.
> >
> >   db.executeSql('CREATE TABLE ...', [], function(...) {
> >     db.executeSql('INSERT INTO ...', []);
> >   });
> >
> > If the CREATE TABLE fails, the insert will never happen. If the INSERT
> > fails, you don't really want the table to be rolled out. If you did,
> > then you want a transaction. There are clearly times where you don't
> > always want a transaction, but want to chain statements.
>
> What if another page dropped the table between the CREATE and the INSERT?

What if you went to insert into a table that someone else had dropped
in any case?

I think Timothy's point is that for the simple case where you really
_do_ intend to execute an ordered sequence of SQL statements which
aren't in a transaction, the new API is a bit more convoluted.  I
think his point is sound, but I'm not certain how important that
use-case is.  Realistically, you're usually either executing a
singleton statement, or you're executing a set of logically connected
statements which want to be in a single transaction.

I think that there might be some value to having better support for a
singleton statement, though.  Right now, your result-set handling is
inside the implicit transaction.  With a singleton executeSql() API
off of Database, your resultset handling could be pushed out of the
transaction, which would be good.

-scott

Brady Eidson | 1 Nov 01:40 2007
Picon

Re: SQL API complex for simple cases

>>> On Wed, 31 Oct 2007, Brady Eidson wrote:
>>>>
>>>> My understanding with this design is that you would get this
>>>> SQLTransaction object back and it would just sit around, not doing
>>>> anything.  When you first call executeSql on it, you kick off the
>>>> transaction steps as they already exist.  Until you call
>>>> executeSql(), it's just a dummy object that doesn't interfere with
>>>> the database at all.
>>>
>>> What if there's a problem with opening the transaction itself? You
>>> don't want to run all the code for preparing the statement only to
>>> find you didn't have a chance for the statement to run in the first
>>> place.
>>
>> While the spec *does* currently enforce preparing the statement at  
>> the
>> time of calling executeSql() just to mark the statement bogus,  
>> "marking
>> the statement bogus" is only a flag that takes effect later during  
>> the
>> transaction effects.
>>
>> Therefore, why is it so necessary to prepare the statement before the
>> transaction is opened?  Why don't we parse and validate the  
>> statement in
>> the transaction steps themselves?
>>
>> If we adopted both of these models (Tims idea and allowing the  
>> statement
>> to be parsed in the transaction steps) and there was a problem with
>> opening the transaction itself, you'd get the
>> SQLTransactionErrorCallback and the statement would never even be
>> touched at all.
>
> I'm talking about:
>
>   var transaction = db.transaction(errorCallback);
>   // the transaction has failed at this point
>   // but we have no way to stop the next few lines from running:
>   ...do lots of work to get the data to put into the transaction...
>   transaction.executeSql('...', [expensiveData], ...);
>
> vs:
>
>   db.transaction(function (transaction) {
>     // this never gets called, since the transaction failed
>     ...do lots of work to get the data to put into the transaction...
>     transaction.executeSql('...', [expensiveData], ...);
>   }, errorCallback);

Interesting.  I think you've swayed me with this argument.

I have an alternative to propose - how about reinstating  
Database.executeSql(), and do something like this.

db.executeSql("select * from table;", [], <SQLStatementCallback>,  
<SQLStatementErrorCallback>, <SQLTransactionErrorCallback>);

This would "fire and forget" a single, individual statement in its own  
transaction.  It would follow transaction steps exactly as they  
currently exist, except it would skip the SQLTransactionCallback  
because the first sql statement to execute is already queued.

This way you could do:

db.executeSql("SELECT * FROM Notes", [], function(tx, results) { //  
Start a new transaction with one sql statement on the queue
	tx.executeSql("INSERT INTO Notes...", [], ...);  // Add a new  
statement to this transaction
	db.executeSql("SOME OTHER SQL STATEMENT", ...); // Start a new  
transaction with its first sql statement queued up
	}, statementErrorCallback, txErrorCallback);

But could also do something as simple as:

db.executeSql("CREATE TABLE Notes (...)", [], NULL, NULL, NULL);

Someone I talked to about this in person was concerned about the  
naming collision of executeSql() - it might be confusing if JS  
developers start making custom classes and you start seeing  
this.executeSql() - is it a database or a sqltransaction?  Perhaps  
naming one of them something other than executeSql().

But I do think this is a reasonable way to A - make it easier to kick  
off an individual statement and B - allows the developer, in the best  
case scenario of no failures, kick off a sql statement that runs to  
completion with *no* callbacks.

I think both of these points are important.

Thanks,
~Brady

Ian Hickson | 1 Nov 01:43 2007
Picon

Re: minor comments on media element cue ranges

On Wed, 31 Oct 2007, Dave Singer wrote:
>
> "When the current playback position of a media element changes (e.g. due 
> to playback or seeking), the user agent must run the following steps. If 
> the current playback position changes while the steps are running, then 
> the user agent must wait for the steps to complete, and then must 
> immediately rerun the steps. (If one iteration takes a long time, this 
> can cause certain ranges to be skipped over as the user agent rushes 
> ahead to "catch up".) "
> 
> Perhaps the parenthesized comment could be prefixed:  (These steps are 
> taken as often as possible or needed;  if one iteration takes a long 
> time, ...)? Just a thought.

Added.

> "3.	If none of the cue ranges in current ranges have their "active"
> boolean set to "false" (inactive) and none of the cue ranges in current ranges
> have their "active" boolean set to "true" (active), then abort these steps. "
> 
> one rather suspects that "other ranges" is  intended for the second test?

Fixed.

> "5.	If there are any cue ranges in other ranges that have their "active"
> boolean set to "true" (active) and have their "pause" boolean set to "true" as
> well, then immediately act as if the element's pause() method had been
> invoked. "
> 
> Does the pause boolean add much over the exit handler?  It seems that if the
> exit is because of a seek, it might be kinda odd to immediately pause again?

Hm, yeah, good point.

The original use case for 'pause' was that it's very hard to have 
frame-accurate pausing if we rely on scripts to do it.

I've changed the spec a bit so that the pausing only happens during normal 
playback, seeking won't trigger it anymore. Is that ok?

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Ian Hickson | 1 Nov 01:50 2007
Picon

Re: SQL API complex for simple cases

On Wed, 31 Oct 2007, Scott Hess wrote:
> > >
> > >   db.executeSql('CREATE TABLE ...', [], function(...) {
> > >     db.executeSql('INSERT INTO ...', []);
> > >   });
> >
> > What if another page dropped the table between the CREATE and the 
> > INSERT?
> 
> What if you went to insert into a table that someone else had dropped in 
> any case?

True.

> I think Timothy's point is that for the simple case where you really 
> _do_ intend to execute an ordered sequence of SQL statements which 
> aren't in a transaction, the new API is a bit more convoluted.  I think 
> his point is sound, but I'm not certain how important that use-case is.  
> Realistically, you're usually either executing a singleton statement, or 
> you're executing a set of logically connected statements which want to 
> be in a single transaction.
> 
> I think that there might be some value to having better support for a 
> singleton statement, though.  Right now, your result-set handling is 
> inside the implicit transaction.  With a singleton executeSql() API off 
> of Database, your resultset handling could be pushed out of the 
> transaction, which would be good.

I entirely agree. I'm just not convinced that we should have this in v1 -- 
there have been a number of arguments put forward that suggest that we 
should delay this until v2.

It's cumbersome, but the danger is that if we make it easy, that we make 
the wrong thing easier than the right thing in several important cases.

On Wed, 31 Oct 2007, Brady Eidson wrote:
> 
> I have an alternative to propose - how about reinstating 
> Database.executeSql(), and do something like this.
> 
> db.executeSql("select * from table;", [], <SQLStatementCallback>, 
> <SQLStatementErrorCallback>, <SQLTransactionErrorCallback>);
> 
> This would "fire and forget" a single, individual statement in its own 
> transaction.  It would follow transaction steps exactly as they 
> currently exist, except it would skip the SQLTransactionCallback because 
> the first sql statement to execute is already queued.

We could do that. I'm not convinced it's of enough benefit to have it in 
v1, though.

> This way you could do:
> 
> db.executeSql("SELECT * FROM Notes", [], function(tx, results) { // Start a
> new transaction with one sql statement on the queue
> 	tx.executeSql("INSERT INTO Notes...", [], ...);  // Add a new
> statement to this transaction
> 	db.executeSql("SOME OTHER SQL STATEMENT", ...); // Start a new
> transaction with its first sql statement queued up
> 	}, statementErrorCallback, txErrorCallback);

Right -- but the fear is that the subtle distinction between 
tx.executeSql() and db.executeSql() in the above code would be the source 
of many hard-to-track bugs.

> But could also do something as simple as:
> 
> db.executeSql("CREATE TABLE Notes (...)", [], NULL, NULL, NULL);
> 
> [...] But I do think this is a reasonable way to A - make it easier to 
> kick off an individual statement and B - allows the developer, in the 
> best case scenario of no failures, kick off a sql statement that runs to 
> completion with *no* callbacks.

I agree. The concern is just that we don't actually want to make this easy 
in the first version.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Scott Hess | 1 Nov 01:50 2007
Picon

Re: SQL API complex for simple cases

On Oct 31, 2007 5:40 PM, Brady Eidson <beidson@...> wrote:
> I have an alternative to propose - how about reinstating
> Database.executeSql(), and do something like this.
>
> db.executeSql("select * from table;", [], <SQLStatementCallback>,
> <SQLStatementErrorCallback>, <SQLTransactionErrorCallback>);

I think SQLTransactionErrorCallback is redudant with
SQLStatementErrorCallback.  Hmm, in fact it cannot work, because
SQLStatementErrorCallback can return things like false to continue,
which doesn't make sense in this case.  So I think:

  db.executeSql("select * from table;", [], <SQLStatementCallback>,
<SQLTransactionErrorCallback>);

would be reasonable.

-scott

Ian Hickson | 1 Nov 02:12 2007
Picon

Re: rel/rev for <form> ?

On Fri, 4 Nov 2005, Charles Iliya Krempeaux wrote:
> 
> The "rel" and "rev" attribute are very useful for adding semantics to 
> both the anchor element -- <a> -- and the link element -- <link>.
> 
> I'd like to suggest that form element -- <form> -- get both "rel" and 
> "rev" attributes.

An interesting idea, but in general we need to find problems before 
finding solutions! :-)

On Fri, 4 Nov 2005, ROBO Design wrote:
> 
> Interesting suggestion. I can't help but wonder what exactly would this 
> change to the "user experience". Rel for LINK and A is changing the user 
> experience in user agents, because they can provide a "fixed" set of 
> keyboard shortcuts (mouse gestures or whatever) for going to the 
> previous/next page, help, home, author, etc.
> 
> What are your ideas about this? What would you like user agents to do 
> based on various <form> rel= attributes?

Good questions.

On Fri, 4 Nov 2005, Charles Iliya Krempeaux wrote:
> 
> There's a number of different "use cases" that this would be very useful 
> for.  I'll try an list some of the ones I think are important.

In general the mapping should be the other way around -- for each problem, 
list possible solutions. Having a solution in search of problems is 
putting the cart before the horse, as they say. :-)

> In writing "user scripts" and "extensions" it is often desirable to look 
> for "semantics" in a page.  For example, consider the semantics given by 
> rel-license <http://microformats.org/wiki/rel-license>. rel-license 
> provides a way of specifying a license for either the whole "document" 
> or part of the "document" it is in.  (It's usually used in the <a> 
> element.)
> 
> There is a Mozilla Firefox extension called MozCC 
> <https://addons.mozilla.org/extensions/moreinfo.php?id=363> which will 
> look for rel-license in a page, and if the URL in the "href" of the 
> rel-license <a> element points to a CreativeCommons license, it then 
> displays "icons" that describe the license.
> 
> Also, Mark Pilgrim has written a (greasemonkey) user script 
> <http://diveintomark.org/projects/greasemonkey/rellicense/> that can 
> detect and "handle" a very large number of licenses.
> 
> Further, web crawlers (and search engines) can make use of this license 
> information.  (For example, Yahoo! has a way of searching only within 
> stuff that are licensed under a CreativeCommons license -- 
> http://search.yahoo.com/cc )
> 
> Also, one could even consider the semantics given by XFN 
> <http://gmpg.org/xfn/>.  (It is rel-based format on the <a> element.) Or 
> any of the other many "rel" and "rev" based formats on the <a> and 
> <link> elements.  (I can list more if you want to hear them.)
> 
> (So hopefully I've shown that "rel" and "rev" based formats can be 
> useful beyond just making "keyboard shortcuts" in the user agent.)

Indeed, for links...

> One of the restriction with <a> and <link> based "rel" and "rev"
> formats is that you implicitly require the HTTP resource (in the
> "href" of the <a> or <link>) element, to be accessed via an HTTP GET. 
> With a <form> element, you are not restricted by this.  With the
> <form> element you can use other HTTP methods (by specifying the
> method you want to use in the "method" attribute of the <form>
> element).  For example:
> 
>     <form method="POST" href="/me.php" rel="api.comment.add">
>         <textarea name="comment"></textarea>
>         <input type="submit" value="Add Comment" />
>     </form>
> 
> Also, another restriction with <a> and <link> based "rel" and "rev" 
> formats is that you have no way of "parametrizing" things.  But with a 
> <form> element you can.  (As shown with the example above too.)

That's a theoretical possible use case... does anyone actually want to do 
this? We should, I feel, concentrate on real problems before adding hooks 
for ideas (especially in this case, where one could use the 'class' 
attribute if one needed to do this).

> Those who have been touting using HTTP how it was designed to be used... 
> although their calling it REST for some reasons... would likely find 
> this type of thing useful too.

If they ask for it, we'll see. :-)

> Also, those that are trying to add increased semantics to HTML under the 
> Micformats banner -- http://microformats.org/ -- would also find this 
> useful.

They mostly seem to be using the 'class' attribute, which here would work 
fine, as far as I can tell.

> This could be used for user agents, for user scripts, for extensions, 
> and for web crawlers.  (There's probably more creative uses for it too.)

It's not clear to me how it could be used usefully.

On Sun, 6 Nov 2005, ROBO Design wrote:
> On Sun, 06 Nov 2005 04:41:58 +0200, Mike Dierken
<mdierken@...> wrote:
> <...>
> > I actually would find it interesting and useful for a the inputs of a 
> > form to have a 'class' attribute that indicates the meaning of the 
> > parameter - and let a web crawler find all the forms that use a 
> > certain class of input parameters.
> > 
> > For example:
> >  <form action="citizens.cgi" method='GET'>
> >   <input name='the-ssn' class='gov.us/identity/individual-tax-id'
> > type='text' />
> >  </form>
> > 
> >  <form action="houses-for-sale.cgi" method='GET'>
> >   <input name='zip' class='gov.us/postal/zip-code' type='text' />
> >  </form>
> > 
> > It would be cool to have a service that discovered these forms and 
> > then provided a search of all the URIs that accepted 
> > social-security-number, or zip-code.

RFC3106, which WF2 mentions, provides a way to do this.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


Gmane