| 00:25 | <annevk> | so it still doesn't work... |
| 00:25 | annevk | didn't get the messages from jgraham for instance |
| 01:11 | <aa> | I had this idea for the database module ... |
| 01:12 | <aa> | the CRUD statements are pretty consistent across implementations, it should be easy, relatively speaking, to spec them, or refer to ANSI SQL. |
| 01:12 | <aa> | it's the creation of the tables and indicies where the real compatibility problems come in. |
| 01:13 | <aa> | what if HTML5 defined DOM APIs to create tables and indicies? This would also allow the types to be defined as standard DOM types, instead of SQL types. |
| 01:13 | <aa> | It would be up to the implementation to do the conversion to whatever it's internal representation is. |
| 01:13 | <aa> | this would provide a real shot at abstracting the implementation (sqlite) from the spec. |
| 01:17 | <Hixie> | sounds reasonable to me |
| 01:17 | <Hixie> | i recommend sending mail to the list suggesting it, let's see what the other vendors think |
| 01:37 | <Lachy_> | Hey Hixie |
| 01:52 | <Hixie> | hey |
| 01:53 | <Hixie> | Lachy_: whatever you did with the blog seems to have helped, "lhunt" is never at the top of the process list anymore |
| 09:15 | <Hixie> | hmmm |
| 09:16 | <Hixie> | so an explicit database.startTransaction() seems to be the only way to address the issues raised with the sql stuff |
| 09:17 | <Hixie> | and splitting the load and error case into two seems good, and having error do a rollback seems good too, except for the point about checking for integrity errors... |
| 09:19 | <Hixie> | maybe rollback only if the function doesn't return false... |
| 09:49 | <Hixie> | hmmm |
| 09:49 | <Hixie> | database.transaction(callback, error_callback); |
| 09:49 | <Hixie> | error_callback gets called if the transaction fails to be created or comitted (or maybe even if it is rolled back?) |
| 09:49 | <Hixie> | callback is a function with one argument, tx, which is an object with an executeSql() method on it |
| 09:49 | <Hixie> | tx.executeSql(sql, args, callback, error_callback); |
| 09:50 | <Hixie> | error_callback gets called for any errors with that statement (even syntax errors), and if it does not return false, the transaction gets rolled back. |
| 09:50 | <Hixie> | callback is the same as the transaction callback |
| 09:51 | <Hixie> | if transaction() is called from within a transaction, it create a new (but not nested) transaction. |
| 09:51 | <Hixie> | transactions commit whenever a callback returns if there are no outstanding calls to executeSql() for that transaction. |
| 09:52 | <Hixie> | but transactions get rolled back if a callback returns false |
| 09:53 | <Hixie> | there's no explicit commit or rollback in v1, but in v2 we add those as well as an executeRawSql(sql, args, callback, error_callback) method on database (whose callback doesn't have any arguments). |
| 09:53 | <Hixie> | any opinions? |
| 09:59 | <Hixie> | oh and changeVersion(old_version, new_version, callback, error_callback) would work like transaction() except that the transaction would be a complete lock and that the version would be checked at the start of the transaction and set when the transaction was comitted |
| 10:16 | <Lachy> | Hixie, what will executeRawSql do differentfly from executeSql? |
| 10:21 | <Hixie> | Lachy: no transaction |
| 10:33 | <hsivonen> | btw, Java makes an interesting case study about strict backwards compat and fixing early design flaws and the rate of adoption |
| 10:34 | <hsivonen> | I just ran a search for references to StringBuffer and it is everywhere |
| 10:34 | <hsivonen> | new code should use StringBuilder |
| 10:34 | <hsivonen> | so the Java6 HotSpot VM takes lock removal to the VM at run time |
| 10:35 | <hsivonen> | so it can mitigate some of the damage of the bad design of StringBuffer |
| 10:42 | <roc> | they did that before StringBuilder was created |
| 10:42 | <roc> | at least some VMs did |
| 10:43 | <hsivonen> | roc: hmm. lock removal / thread-biased locks were mentioned as a Java6 HotSpot feature |
| 10:44 | <hsivonen> | Hashtable and Vector are pretty pervasive, too |
| 10:44 | <hsivonen> | which sucks considering that HashMap and ArrayList are even safe for concurrent reads |
| 21:16 | <jgraham_> | /me curses xml |
| 21:17 | <jgraham_> | Wow I managed to make a syntax error whilst complaining about a language for its syntax-error intolerance |
| 21:22 | <hendry> | hsivonen: just checking out http://packages.qa.debian.org/w/w3c-markup-validator.html |
| 22:46 | <Hixie> | wow, with the amount of time the forms tf has spent discussing when to discuss things, you'd think they could have discussed things by now |