- From: Dan Forsberg <dforsber@gmail.com>
- Date: Sat, 21 Nov 2009 11:13:58 +0200
- To: public-webapps@w3.org
- Message-ID: <938de3520911210113g7b749c40j5b1226cb784fcd78@mail.gmail.com>
Hello, 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. Cheers, - Dan Forsberg http://forsberg.fi/ ps. This is my personal comment as I'm not working for any company at the moment.
Received on Saturday, 21 November 2009 13:41:27 UTC