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 developers are already used to ... do what? Storing text and other variable length data in flat tables? Where did you find such developers? I understand need of SQL DB on the server but data on the client has different structure as a rule. Do you know any example where client storage as SQL DB is *really* needed? And by the way what flavor of sql is used? Transactions, stored procedures / triggers ? Or we will declare that we all should have to use SQLite only? (I have nothing against SQLite per se - it is good) Some particular company may find that for their particular tasks SQL is exactly what is needed but I do not think that it is wise to assume that all storage needs will fit in procrustean bed of SQL/ relational DBs and all UA vendors will agree to use the same version of SQLite. I suspect that initial simple *Berkeley DB* alike proposal is what really needed and enough in most cases. Andrew Fedoniouk. http://terrainformatica.com
Re: [whatwg] Why SQL? was: Comments on updated SQL API
On Sep 24, 2007, at 11:45 PM, Andrew Fedoniouk wrote: 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 developers are already used to ... do what? Storing text and other variable length data in flat tables? Where did you find such developers? Web App developers are used to using SQL to access storage on the server. Web apps that add offline support are likely to want to store data on the client with a similar structure to data on the server. If some form of object persistence is desired, it could be implemented on top of SQL, and perhaps once it is proven as a storage model some built-in approach could be standardized. I suspect that initial simple *Berkeley DB* alike proposal is what really needed and enough in most cases. Berkeley DB is just an on-disk hashtable. Such simple key/value story with no support for complex queries can already be found in the Storage API. http://www.whatwg.org/specs/web-apps/current-work/#the-storage . Low-structure storage can indeed be good for simple cases. (Actually, the Berkeley DB API has a lot more to it than that, but exposing something resembling the full API would require a large amount of API surface area.) Regards, Maciej
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. most app developers are already used to ... do what? Storing structured data in SQL databases. I understand need of SQL DB on the server but data on the client has different structure as a rule. Actually the primary use case for this is offline applications caching server data on the client, where in fact the data ends up being exactly the same data as on the server. I expect many authors will end up merely replicating their schema on the client, in fact. Do you know any example where client storage as SQL DB is *really* needed? Almost any offline application, like offline Web mail systems, would be a good example. Given the demand for the feature (so much so that, e.g., the Google Gears team prioritised it to being one of the first three things to implement as browser extensions), I have no fear that this is something that few people will find useful. And by the way what flavor of sql is used? Transactions, stored procedures / triggers ? Or we will declare that we all should have to use SQLite only? (I have nothing against SQLite per se - it is good) My intent is to await implementation feedback on this matter. SQLite seems like a good starting point, though. Some particular company may find that for their particular tasks SQL is exactly what is needed but I do not think that it is wise to assume that all storage needs will fit in procrustean bed of SQL/ relational DBs Indeed, that's why we have a variety of other storage solutions like the globalStorage and sessionStorage APIs, cookies, server-side storage, etc. and all UA vendors will agree to use the same version of SQLite. Different browsers will always be at different levels of development. Once we (the Web community) have more experience in this field, we can define a common set of functionality that all UAs must support, much like we do with all other features. I suspect that initial simple *Berkeley DB* alike proposal is what really needed and enough in most cases. It's possible. However, most implementation feedback at this point has encouraged us to follow an SQL route. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why SQL? was: Comments on updated SQL API
Maciej Stachowiak wrote: Web App developers are used to using SQL to access storage on the server. Web apps that add offline support are likely to want to store data on the client with a similar structure to data on the server. If some form of object persistence is desired, it could be implemented on top of SQL, and perhaps once it is proven as a storage model some built-in approach could be standardized. 1) Far not all web services have relational DB on the back end. Google and Yahoo web services as an example. 2) For the cases when there is a SQL DB data are delivered to the client in form of JSON or XML that needs to be deserialised back to flat representation. It is pretty natural to store/manipulate data as is. JS already provide enough constructions to do this: maps (hash tables) and vectors(arrays) . If someone needs things like select() to query complex data structures then it is a matter of JS itself. See http://code.google.com/p/trimpath/wiki/TrimQuery as an example. Things like TrimQuery backed by simple Object.persist() will do the job *when it is really needed*. I suspect that initial simple *Berkeley DB* alike proposal is what really needed and enough in most cases. Berkeley DB is just an on-disk hashtable. Such simple key/value story with no support for complex queries can already be found in the Storage API. http://www.whatwg.org/specs/web-apps/current-work/#the-storage. Low-structure storage can indeed be good for simple cases. (Actually, the Berkeley DB API has a lot more to it than that, but exposing something resembling the full API would require a large amount of API surface area.) If it is storage API already why do we need SQL then? I think either storage API or SQL API shall be eliminated. Having them both ... I am not against new things really. It just appears as UA will look like Christmas tree one day. Each member of the family is adding their own stuff. And someone put there SQL engine because it happens to lie on the shelf nearby and granddad decide that his old canvas will also look cool there and so on. For Christmas tree such decoration approach would work but for serious system design ... Client storage shall be as simple and universal as possible to be short. Andrew Fedoniouk. http://terrainformatica.com
Re: [whatwg] Why SQL? was: Comments on updated SQL API
Andrew Fedoniouk wrote: I am not against new things really. It just appears as UA will look like Christmas tree one day. Each member of the family is adding their own stuff. And someone put there SQL engine because it happens to lie on the shelf nearby and granddad decide that his old canvas will also look cool there and so on. For Christmas tree such decoration approach would work but for serious system design ... Client storage shall be as simple and universal as possible to be short. I wonder about the term SQL appearing in HTML specs too.. -dean
