Re: [whatwg] Offline Web Apps
On 24/09/2007, at 10:45 PM, Robert O'Callahan wrote: snip 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 synchronous ones, and people will end up doing silly things (excessive reads, etc) using a synchronous API, eg. synchronous api for large reads, or many sequential small synchronous reads -- either of which will block the main thread in excitingly bad ways. I would make the argument that anyone making a real webapp (online or offline) is likely to have at least *some* experience with async-xhr, so should have to much difficulty with an async api for reading/writing. Also, I'm not sure how a web app can be expected to know the encoding of a text file on disk. The same way that any other app does --- guess based on the extension and expected usage? --- now that we've all standardized on meta-data-less file systems :-(. I suppose an app could examine the first chunk of the file and then re-read the file with a better guess. The MacOS fs appears to store encoding, but then maybe editors are more careful about including the BOM, etc in files that they save. Surely it would be possible for the browser to transparently store the encoding in the event that none was defined by the developer? Rob --Oliver
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] Offline Web Apps
On Sep 24, 2007, at 10:45 PM, Robert O'Callahan wrote: 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. Probably the methods should have names based on read or the like (read(), readAsText(), etc) to indicate this. Also, they should arguably be asynchronous since reading from the disk can be slow, especially for large files, and it is undesirable to block the main thread. For small files, synchronous reading is OK. Perhaps there should be a separate whiz-bang asynchronous API ... it could support partial reads too. What kind of file is small enough is a matter of judgment and depends on device performance characteristics. I tried the following experiment to estimate how much time could be taken by synchronous cold reads of a moderate number of files (assuming multi-file support in input type=file and naiive use of the synchronous read API): $ time cat ~/Pictures/*.jpg /dev/null real0m1.135s user0m0.007s sys 0m0.076s This is on a pretty fast machine with a local filesystem. I have 76 .jpg files totaling about 19M in size. 1.13 seconds seems like an unacceptable length of time to block the UI, and it could easily be much worse for, say, a batch photo upload or an upload of a moderately large video file. So I suspect that, much like synchronous XMLHttpRequest, synchronous file reads will lead to excessive UI lockups in bad circumstances unanticipated by the app author. Also, I'm not sure how a web app can be expected to know the encoding of a text file on disk. The same way that any other app does --- guess based on the extension and expected usage? --- now that we've all standardized on meta-data-less file systems :-(. I suppose an app could examine the first chunk of the file and then re-read the file with a better guess. The OS and the UA can often make a better guess, so I think the option to let the UA decide the encoding should at least be provided. Here are some sources of info that the UA has but the web app doesn't (at least without doing a separate binary read of the file first and possibly significant computation): 1) OS-level metadata, as for example in Mac OS X: $ xattr -l plan.txt com.apple.TextEncoding: UTF-8;134217984 2) Checking for a BOM. 3) Heuristics for specific file types, like looking for meta charset in HTML files or the encoding pseudo-attribute in an XML declaration. 4) General character set autodetection algorithms through statistical methods or similar. 5) Knowledge of the user's locale (useful for some legacy systems where default text encoding is determined by locale). 6) Knowledge of platform encoding conventions. Regards, Maciej
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] Offline Web Apps
On 9/25/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: The OS and the UA can often make a better guess, so I think the option to let the UA decide the encoding should at least be provided. Here are some sources of info that the UA has but the web app doesn't (at least without doing a separate binary read of the file first and possibly significant computation): Our File implementation lets the browser choose the encoding if an empty encoding is passed by the app, but there might be a nicer/more obvious way to do that. -dave
Re: [whatwg] Offline Web Apps
On Sep 25, 2007, at 8:55 AM, Dave Camp wrote: On 9/25/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: The OS and the UA can often make a better guess, so I think the option to let the UA decide the encoding should at least be provided. Here are some sources of info that the UA has but the web app doesn't (at least without doing a separate binary read of the file first and possibly significant computation): Our File implementation lets the browser choose the encoding if an empty encoding is passed by the app, but there might be a nicer/more obvious way to do that. I think it would be nice to make the argument optional so you can just omit it instead of passing . That or have two different methods, since I would not expect requesting a specific encoding to be the common case. Regards, Maciej
Re: [whatwg] executeSql API is synchronous
On Sep 24, 2007 9:22 PM, Ian Hickson [EMAIL PROTECTED] wrote:
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 can be iterated
on a different thread).
This is basically what the spec does now. There is some debate about
whether the results should actually be an Array or not though, to allow
for a lazy caching implementation if desired.
I like the current specification of ResultSet:
http://www.whatwg.org/specs/web-apps/current-work/#sqlresultset
If you are not planning on changing it, you can stop reading now :)
Otherwise, read on.
When you read from SQLite (and probably other databases) you acquire a
read lock (shared). This lock needs to be released explicitly
because no writes can occur while it is open.
There are basically three options for determining the lifetime of this lock:
* Push: The implementation reads all the results immediately, releases
the lock, and closes. This is what I'm advocating.
* Pull: caller requests rows as needed and explicitly closes the lock
when it is done. This is what Gears does today.
* A race! The implementation returns immediately and starts populating
results in the background. When it's done, it releases the lock. If
the caller requests a row that isn't available yet, the request blocks
until it is.
I think that pure pull is a bad idea because callers always forget to
close the resultset. You cannot rely on GC because it is
non-deterministic.
The race doesn't seem that great either because if the caller does this:
alert(resultset.rows[resultset.rows.length])
We block the UI and lose all the benefit of having the API be
asynchronous in the first place.
Therefore push seems simplest and best IMO. It's true that it is
inefficient in certain special cases, but we could add a different
push API (with a callback on each row) to work around that problem if
it really is a problem.
- a
Re: [whatwg] executeSql API is synchronous
On Sep 25, 2007, at 10:23 AM, Aaron Boodman wrote:
On Sep 24, 2007 9:22 PM, Ian Hickson [EMAIL PROTECTED] wrote:
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 can be
iterated
on a different thread).
This is basically what the spec does now. There is some debate about
whether the results should actually be an Array or not though, to
allow
for a lazy caching implementation if desired.
I like the current specification of ResultSet:
http://www.whatwg.org/specs/web-apps/current-work/#sqlresultset
If you are not planning on changing it, you can stop reading now :)
Otherwise, read on.
I agree that the actual I/O to the database should be done up front.
However, it should be possible to make the conversion from SQLite's
native data types to JavaScript datatypes lazy (such type conversion
can have nontrivial cost, especially in bulk). To do that and get
Array-like behavior, you need either a custom Array subclass, or a
class that doesn't inherit the Array implementation but does have the
Array prototype in its prototype chain. But the current spec rules
this out by requiring the result to be a native Array. Furthermore,
being a native Array requires support for mutation, which again
makes custom strategies involving lazy type conversion more challenging.
I would propose requiring that the row list object must have number-
named properties for the contents, a read-only length property, and
all Array prototype functions that do not modify the array somewhere
in its prototype chain (this would include filter, forEach, map, but
not sort or pop). I am not even sure the last part is necessary,
because using Array.forEach is not *that* much more convenient than a
for loop and is likely to be less efficient in many JS
implementations. But if we want Array operations to be available, I'd
suggest doing it in a way that does not constrain implementations to
use a native Array.
Regards,
Maciej
Re: [whatwg] executeSql API is synchronous
On Sep 25, 2007 11:08 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: I agree that the actual I/O to the database should be done up front. However, it should be possible to make the conversion from SQLite's native data types to JavaScript datatypes lazy (such type conversion can have nontrivial cost, especially in bulk). To do that and get Array-like behavior, you need either a custom Array subclass, or a class that doesn't inherit the Array implementation but does have the Array prototype in its prototype chain. But the current spec rules this out by requiring the result to be a native Array. Furthermore, being a native Array requires support for mutation, which again makes custom strategies involving lazy type conversion more challenging. I would propose requiring that the row list object must have number- named properties for the contents, a read-only length property, and all Array prototype functions that do not modify the array somewhere in its prototype chain (this would include filter, forEach, map, but not sort or pop). I am not even sure the last part is necessary, because using Array.forEach is not *that* much more convenient than a for loop and is likely to be less efficient in many JS implementations. But if we want Array operations to be available, I'd suggest doing it in a way that does not constrain implementations to use a native Array. Ah, that makes sense. A special purpose class for the rows property is fine with me. I don't feel that strongly about forEach and friends. - a
Re: [whatwg] executeSql API is synchronous
On 9/25/07, Aaron Boodman [EMAIL PROTECTED] wrote:
On Sep 25, 2007 11:08 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
Ah, that makes sense. A special purpose class for the rows property is
fine with me. I don't feel that strongly about forEach and friends.
Speaking of forEach, what do you think of (pardon any syntax errors,
writing straight into gmail window):
db.forEach(SELECT * FROM pages;, function(row) {
this.innerHTML += lia href=\ + row.url + \ + row.title +
/a/li;
}, document.getElementById(pages))
and...
document.getElementById(pages).innerHTML = ul + db.map(SELECT *
FROM pages, function(row) {
return lia href=\ + row.url + \ + row.title + /a/li
}).join() + /ul;
Why expose rows collection at all?
:DG
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
Hi, Oliver Hunt wrote: 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 repeatedly. The first problem is the repeated drawing of old rects, this is due to the context path not being cleared by draw rect and fill rect which is the behaviour present in Safari 2 and Firefox 2. While I've discussed the issue with Hixie in the past (and to an extent agree with him) the Firefox 3 nightlies do not appear to have adopted this behaviour, leaving us in a position where we have to choose between compatibility and compliance which is awkward. For Firefox 3, there is a patch in our bugzilla, at https://bugzilla.mozilla.org/show_bug.cgi?id=296904 that could fix this issue -- that is, strokeRect/fillRect/drawImage would no longer reset the current path. However, I'm confused by your comment -- Firefox 2 and current Firefox 3 trunk's behaviour is identical, as far as I know; that is, the current path is being reset on strokeRect/fillRect. (Did you mean due to the context path being cleared ...?) Given that this is somewhat of an edge case, would it make sense to alter the spec here? The second problem is that the rules for drawing rects/adding rects to the path require us to throw an exception on negative width/height, once again Firefox 3 does not match this behaviour, putting us in a position where we need to choose between compatibility and compliance. In this case however it is relatively easy to make the argument that an exception should _not_ be thrown, as it means webapp developers either need to litter their code with exception handlers or add significant logic to ensure that their apps do not unexpectedly terminate. The possible responses to drawing a rect with negative dimensions are (excluding the unappealing exception behaviour currently defined) to cull/ignore them (as we do with 0-sized rects), to normalise them (the current behaviour of firefox, and the behaviour expected by those apps that are affected by it), or to normalise them and treat the negative dimensions as an implicitly reversing the winding direction. Both Opera and Safari 3 match the specification behaviour in both these cases, which results in multiple sites failing to render. I agree that throwing an exception is probably unnecessary, as there are very few other places in the API where such exceptions are thrown (except when the input is of clearly the wrong type). Normalizing seems to be the most useful approach -- that is, the functions that take x,y,w,h would be defined to create a rectangle with its two corners being (x,y) and (x+w,y+h), regardless of the sign of w/h, but I would be ok with making such rectangles also be ignored. It's also fairly easy for authors to implement their own versions of strokeRect/fillRect with any of these semantics (well, harder if they were to preserve the current path). This is less of an edge case than the previous issue, IMO, so we should try to figure out what the most useful (and most straightforward) thing is to happen here. I think that it would be important to ship compatible canvas implementations in the next versions of Firefox, Safari, and Opera; so if we have to break existing users to do so, I hope that they will forgive us for the compliance bumps and put in workarounds (e.g., to call beginPath() after every strokeRect/fillRect), but it would be better if we could avoid having to do that. - Vlad
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
On 25/09/2007, at 1:26 PM, Vladimir Vukicevic wrote: Hi, Oliver Hunt wrote: 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 repeatedly. The first problem is the repeated drawing of old rects, this is due to the context path not being cleared by draw rect and fill rect which is the behaviour present in Safari 2 and Firefox 2. While I've discussed the issue with Hixie in the past (and to an extent agree with him) the Firefox 3 nightlies do not appear to have adopted this behaviour, leaving us in a position where we have to choose between compatibility and compliance which is awkward. For Firefox 3, there is a patch in our bugzilla, at https:// bugzilla.mozilla.org/show_bug.cgi?id=296904 that could fix this issue -- that is, strokeRect/fillRect/drawImage would no longer reset the current path. However, I'm confused by your comment -- Firefox 2 and current Firefox 3 trunk's behaviour is identical, as far as I know; that is, the current path is being reset on strokeRect/fillRect. (Did you mean due to the context path being cleared ...?) Given that this is somewhat of an edge case, would it make sense to alter the spec here? Firefox 2/3 and Safari 2 clear the context's path on strokeRect/ fillRect, this violates the spec -- but there are many websites that now rely on such behaviour despite the behaviour defined in hmtl5. This means that those browsers that match the current draft (eg. Safari 3 and Opera 9.x) fail to render these websites correctly. Ideally there would be a distinct Path object, that was separate from the canvas context but we can't have everything :D Unfortunately it isn't really an edge case as it's a relatively common occurance -- people expect that the rect drawing function (for example) will clear the path, so expect clearRect (myCanvasElement.width, myCanvasElement.height) to clear the rect and reset the path, and other similarly exciting things :-/ I agree that throwing an exception is probably unnecessary, as there are very few other places in the API where such exceptions are thrown (except when the input is of clearly the wrong type). Normalizing seems to be the most useful approach -- that is, the functions that take x,y,w,h would be defined to create a rectangle with its two corners being (x,y) and (x+w,y+h), regardless of the sign of w/h, but I would be ok with making such rectangles also be ignored. It's also fairly easy for authors to implement their own versions of strokeRect/fillRect with any of these semantics (well, harder if they were to preserve the current path). This is less of an edge case than the previous issue, IMO, so we should try to figure out what the most useful (and most straightforward) thing is to happen here. I agree, throwing an exception in this case seems abhorrent and not in keeping with the behaviour of other portions of the canvas api. I quick study would indicate that those websites that assume negative dimensions will work seem to expect normalisation rather than culling, so in the interests of compatibility that is probably the best approach of the available options. I think that it would be important to ship compatible canvas implementations in the next versions of Firefox, Safari, and Opera; so if we have to break existing users to do so, I hope that they will forgive us for the compliance bumps and put in workarounds (e.g., to call beginPath() after every strokeRect/fillRect), but it would be better if we could avoid having to do that. Agreed. In the latter case this seems trivial as almost anything other than throwing an exception seems to be a technical improvement and the alternatives (including retaining old behaviour) all seem equally reasonable. In the case of the former i'm not sure what the best solution is, i think that resetting the path only on beginPath() seems to be a much more sensible behaviour, but that does clash with a reasonable number of existing sites :( - Vlad --Oliver
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
On 25/09/2007, Oliver Hunt [EMAIL PROTECTED] wrote: Firefox 2/3 and Safari 2 clear the context's path on strokeRect/ fillRect, this violates the spec -- but there are many websites that now rely on such behaviour despite the behaviour defined in hmtl5. This means that those browsers that match the current draft (eg. Safari 3 and Opera 9.x) fail to render these websites correctly. How hard would it be to get those sites fixed? If there are problems in something like PlotKit or Reflection.js, which lots of people copy onto their own servers, then it would be a pain to break compatibility. If it's just sites like canvaspaint.org where there is a single copy of the code and the developer still exists and can update it, it seems a much less significant problem to break compatibility. Unfortunately it isn't really an edge case as it's a relatively common occurance -- people expect that the rect drawing function (for example) will clear the path, so expect clearRect (myCanvasElement.width, myCanvasElement.height) to clear the rect and reset the path, and other similarly exciting things :-/ Firefox also resets the path on drawImage and putImageData, unlike Opera and Safari 3 - do people depend on that behaviour too? --Oliver -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
On 25/09/2007, at 2:19 PM, Philip Taylor wrote: On 25/09/2007, Oliver Hunt [EMAIL PROTECTED] wrote: Firefox 2/3 and Safari 2 clear the context's path on strokeRect/ fillRect, this violates the spec -- but there are many websites that now rely on such behaviour despite the behaviour defined in hmtl5. This means that those browsers that match the current draft (eg. Safari 3 and Opera 9.x) fail to render these websites correctly. How hard would it be to get those sites fixed? If there are problems in something like PlotKit or Reflection.js, which lots of people copy onto their own servers, then it would be a pain to break compatibility. If it's just sites like canvaspaint.org where there is a single copy of the code and the developer still exists and can update it, it seems a much less significant problem to break compatibility. I've only seen it on major sites -- it just appears that FFX3 is unlikely to be updated to match the correct behaviour, which is worrying in terms of compatibility. Certainly I would prefer that FFX behaviour was fixed as the spec'd behaviour is much more technically sane. Unfortunately it isn't really an edge case as it's a relatively common occurance -- people expect that the rect drawing function (for example) will clear the path, so expect clearRect (myCanvasElement.width, myCanvasElement.height) to clear the rect and reset the path, and other similarly exciting things :-/ Firefox also resets the path on drawImage and putImageData, unlike Opera and Safari 3 - do people depend on that behaviour too? That honestly never occurred to me :-O I can't see why people would expect it to, but i wouldn't have thought they'd think that about fill/strokeRect :-/ --Oliver -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Offline Web Apps
Which other application exactly do you have in mind? The applications I know mostly ask the opener. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Callahan Sent: Tuesday, September 25, 2007 7:46 AM To: Maciej Stachowiak Cc: Křištof Želechovski; Dave Camp; [EMAIL PROTECTED]; Ian Hickson; Aaron Boodman Subject: Re: [whatwg] Offline Web Apps On 9/23/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: Also, I'm not sure how a web app can be expected to know the encoding of a text file on disk. The same way that any other app does --- guess based on the extension and expected usage? --- now that we've all standardized on meta-data-less file systems :-(. I suppose an app could examine the first chunk of the file and then re-read the file with a better guess. Rob
Re: [whatwg] Offline Web Apps
In that case we go back to structured files. Structured files should be read using specialized parsers, not plain character streams. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Hunt Sent: Tuesday, September 25, 2007 8:00 AM To: [EMAIL PROTECTED] Cc: Aaron Boodman; Dave Camp; Maciej Stachowiak; [EMAIL PROTECTED]; Křištof Želechovski; Ian Hickson Subject: Re: [whatwg] Offline Web Apps Surely it would be possible for the browser to transparently store the encoding in the event that none was defined by the developer?
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
