Re: [whatwg] Why SQL? was: Comments on updated SQL API

Ian Hickson wrote: On Mon, 24 Sep 2007, Andrew Fedoniouk wrote: I have a question: why SQL was chosen as client side storage for Web Applications? Because it's what most app developers are already used to -- the M in the widely used traditional LAMP stack is SQL. "most app devel

Re: [whatwg] Offline Web Apps

On 24/09/2007, at 10:45 PM, Robert O'Callahan wrote: For small files, synchronous reading is OK. Perhaps there should be a separate whiz-bang asynchronous API ... it could support partial reads too. I would be concerned about this -- for many people async APIs seem scary compared to sy

Re: [whatwg] Offline Web Apps

On 9/23/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > Obviously, if the way to get the contents as text requires providing > the encoding, then it has to be a method. My comment was about the no- > argument methods. But you have a point that reading from disk is not a > simple get operation.

Re: [whatwg] Why SQL? was: Comments on updated SQL API

On Mon, 24 Sep 2007, Andrew Fedoniouk wrote: > > I have a question: why SQL was chosen as client side storage for Web > Applications? Because it's what most app developers are already used to -- the M in the widely used traditional LAMP stack is SQL. -- Ian Hickson U+1047E

Re: [whatwg] executeSql API is synchronous

On Sun, 23 Sep 2007, Aaron Boodman wrote: > > db.executeSQL("select * from person where id = ?", [42], function(result) { > // result is an array of objects > }); > > Another issue that this design addresses is that it avoid blocking the > UI for IO while iterating the results (all the results

Re: [whatwg] executeSql API is synchronous

On Sun, 23 Sep 2007, David wrote: > > Can someone point me out when the SQLCallback is called exactly ? > Is it when the ResultSet is full or, as soon as the first row is available ? I've tried to make this clearer now. > What if I want to handle the RS by blocks of 100 rows ? Why wouldn't you

Re: [whatwg] Comments on updated SQL API

On Sat, 22 Sep 2007, Timothy Hatcher wrote: > > The callback syntax is nice but the implicit thread-global transaction > is confusing and can lead to programmer error and unneeded database > locking. There isn't really a thread-global transaction, the transactions are per-sequence-of-executeSql

[whatwg] Why SQL? was: Comments on updated SQL API

I have a question: why SQL was chosen as client side storage for Web Applications? As far as I understand flat tables are not the best thing for storage of mostly non structured data. Think about storage of e-mail messages. I'd expect something close to mini file system associated with some doma

Re: [whatwg] Comments on updated SQL API

On Sat, 22 Sep 2007, Maciej Stachowiak wrote: > > Sometimes it's useful to schedule multiple SQL queries in a single > transaction at once, without a separate async callback for each. We > discussed possible syntax something like the following: > > void executeSql(in sequence sqlStatements, in

Re: [whatwg] Comments on updated SQL API

On Sat, 22 Sep 2007, Aaron Boodman wrote: > > 4.12.3, step 3: > > I don't think you should implicitly join active transactions unless > you're inside a callback from a previous executeSql call. That's what the spec requires. I've tried to make it a bit clearer. > Otherwise all code that wants

Re: [whatwg] Comments on updated SQL API

On Sat, 22 Sep 2007, Maciej Stachowiak wrote: > > Mostly I like the new API (no surprise to Ian I'm sure). > > http://www.whatwg.org/specs/web-apps/current-work/#sql Great! > A few comments. I think putting the currentRow accessors directly on the > ResultSet is a bit of an odd choice. Well,

Re: [whatwg] SQL API error handling

On Thu, 20 Sep 2007, Anne van Kesteren wrote: > > The SQL API doesn't seem to define how to deal with errors, such as: > > * Bogus SQL statements Defined. > * SQL statements that are not supported for security reasons Defined to be the same as bogus statements. > * SQL statements that are

Re: [whatwg] executeSql API is synchronous

On Wed, 8 Aug 2007, Maciej Stachowiak wrote: > > The executeSql() API returns a result synchronously. In general, SQL > databases may be slow to access since they need to be read from disk, > and if the database is not open already there's unlikely to be a ready > cache. This may make it hard t

[whatwg] Compatibility problems with HTML5 Canvas spec.

Hi All, We've encountered a number of website compatibility issues in WebKit due to our adherence to the new Canvas specifications -- a good example of this is rect drawing at http://canvaspaint.org The most obvious issues can be shown if you use the draw rect tool and resize the rect rep

Re: [whatwg] Form Serialization Idea

I've cross-posted. Bad. I'm putting this back on WHAT WG It's a web-app thing, but related to HTML5. HTML 5 has two lists. On 9/24/07, Subbu Allamaraju <[EMAIL PROTECTED]> wrote: > Does this approach take the enctype into account? What is the behavior if a > given form can't be serialized for a g

Re: [whatwg] [wf2] :read-write pseudoclass description issue

Ah Let me rephrase the proposal: replace "A disabled control can still match this pseudo-class; the states are orthogonal." with "A disabled control can still match this pseudo-class; the disabled and read-write states are orthogonal." current description could fool more people :) Regards

Re: [whatwg] [wf2] :read-write pseudoclass description issue

Quoting Rikkert Koppes <[EMAIL PROTECTED]>: > [...] A > disabled control can still match this pseudo-class; the states are > orthogonal. > > I believe the term "orthogonal" is incorrect here. :read-write is orthogonal to :disabled. That's correct. -- Anne van Kesteren

[whatwg] [wf2] :read-write pseudoclass description issue

http://www.whatwg.org/specs/web-forms/current-work/#relation :read-only Matches form control elements that have the |readonly | attribute set, and to which the |readonly