Re: [webdatabase] Why does W3C have to worry about SQL dialect?
On Sat, Nov 21, 2009 at 10:13 PM, Dan Forsberg dfors...@gmail.com wrote: 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. Then your app depends on features that aren't defined in any standard. We would prefer to avoid people writing content that only works with a certain proprietary plugin. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
[webdatabase] Why does W3C have to worry about SQL dialect?
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.
Re: [webdatabase] Why does W3C have to worry about SQL dialect?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Forsberg wrote: 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. It sounds like you have just described the WebSimpleDB proposal. It provides the interface to the DB at the level that one can implement any query language on top of the DB, whether it be SQLite's SQL, MySQL's SQL, JSONQuery, FIQL, or to some degree even CouchDB style views. Of course these can be implemented by a DB vendor or anyone else. We at Dojo are certainly hoping to provide at query language adapter (you mentioned you are using Dojo), I have some FIQL code in the works. - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksH8O0ACgkQ9VpNnHc4zAyIaACdFliR7itZdJZOU0mQNUBjgSPz B18AmwTS1YmsRPXbgyOmAO7mspc5zR2g =sUAs -END PGP SIGNATURE-
