W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

[webdatabase] Why does W3C have to worry about SQL dialect?

From: Dan Forsberg <dforsber@gmail.com>
Date: Sat, 21 Nov 2009 11:13:58 +0200
Message-ID: <938de3520911210113g7b749c40j5b1226cb784fcd78@mail.gmail.com>
To: public-webapps@w3.org

I have a LAMP based database application without JS on my server (well, with
PostgreSQL). Now I want to make it Ajax/Offline compliant. I've done all my
data manipulation/querying with pre-coded SQL statements into the PHP
application. In last week I've tried to find out the right way to do it but
noticed that this is on-going-work. We have Gears, Dojo Offline,
UltraLiteWeb, .. and SQLite supported on Gecko, WebKit, and with Gears in
IE. But the problem is general syncing support and different evolving
non-standard interfaces (sigh).

Syncing should happen under the hood. A web developer should not need to
worry about how to actually do the syncing.

In SQL case, it would be nice to have the same script work on client side
with SQL so that whenever I change the queries etc. I can use the same
interface on both endpoints. But instead of sticking to SQLite or whatever
DB format, why should W3C worry about the SQL dialect at all?

Just standardize the interface to the (SQL) database and let DB vendors
create browser plugins. This interface you need to define anyway. Plus,
allow DB specific language passing to the plugin (e.g., like SQL). Simple
and efficient. In case of single file based storage the browser can open one
file for each domain/security boundary etc. you figure it out.

Yes, and I'm definetly in favor of SQL. You can use it in a very simple way,
but it is also powerful to do more complex things.

- Dan Forsberg

ps. This is my personal comment as I'm not working for any company at the
Received on Saturday, 21 November 2009 13:41:27 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:21 UTC