Persistent client side storage for your persistent needs
By João EirasxErath. Wednesday, March 3, 2010 2:50:50 PM
In the beginning of 2009 we started developing support for the persistent storage APIs, Web Storage and Web SQL Databases. Meanwhile, with the Opera 10.50 release cycle, the feature was made public.
Despite being two separate APIs, they share some common design. Both benefit from quota control, which can be tweaked in opera:config. Whenever a web site tries to go over its allowed quota, the user will be requested for more. Privacy mode, delete private data and widgets are also obviously supported. All web storage areas and databases are visible in opera:webstorage and opera:webdatabases respectively. Lastly, all data is placed under the folder "pstorage" in your profile folder.
Currently, we support all features in the Web Storage specification, with the exception of structured storage and the storage mutex. Testing also showed that our Web Storage implementation has nice performance.
Naturally, we chose SQLite as the database engine for Web Databases. SQLite, being in the public domain, allowed us to include it in Opera. Also, we can ensure compatibility with the other browsers that also support Web Databases. SQLite integration went without issues: the online documentation is very good, and allowed us to do everything we wanted. We commend the SQLite project for the great work they are doing.
Unfortunately, the binary footprint of SQLite does not make it perfectly usable in many of the less powerful devices that Opera ships on, so the feature might not be available everywhere. Therefore you should always do proper feature detection before attempting to use the feature, as shown below.
Some people have asked if we should support replacing the database engine with something else, like MySql. Currently, there are no plans to do so. Other databases engines are not perfectly interoperable with SQLite, and the integration with an external DBMS is not trivial.
Web Storage support in Dragonfly is already available, and we hope in the future to have nice SQL development tools builtin. For details about the APIs you can refer to the specifications linked above, and to dev.opera.com.
Despite being two separate APIs, they share some common design. Both benefit from quota control, which can be tweaked in opera:config. Whenever a web site tries to go over its allowed quota, the user will be requested for more. Privacy mode, delete private data and widgets are also obviously supported. All web storage areas and databases are visible in opera:webstorage and opera:webdatabases respectively. Lastly, all data is placed under the folder "pstorage" in your profile folder.
Currently, we support all features in the Web Storage specification, with the exception of structured storage and the storage mutex. Testing also showed that our Web Storage implementation has nice performance.
Naturally, we chose SQLite as the database engine for Web Databases. SQLite, being in the public domain, allowed us to include it in Opera. Also, we can ensure compatibility with the other browsers that also support Web Databases. SQLite integration went without issues: the online documentation is very good, and allowed us to do everything we wanted. We commend the SQLite project for the great work they are doing.
Unfortunately, the binary footprint of SQLite does not make it perfectly usable in many of the less powerful devices that Opera ships on, so the feature might not be available everywhere. Therefore you should always do proper feature detection before attempting to use the feature, as shown below.
if (window.openDatabase)
{
/* use web databases */
}
else
{
/* fallback */
}
Some people have asked if we should support replacing the database engine with something else, like MySql. Currently, there are no plans to do so. Other databases engines are not perfectly interoperable with SQLite, and the integration with an external DBMS is not trivial.
Web Storage support in Dragonfly is already available, and we hope in the future to have nice SQL development tools builtin. For details about the APIs you can refer to the specifications linked above, and to dev.opera.com.

Charles SchlossChas4 # Wednesday, March 3, 2010 3:15:53 PM
Barraco Mármol Jerónimojerobarraco # Wednesday, March 3, 2010 3:33:10 PM
this is very weird feature when you analize it.
there was a trend actually to remove all information on the client side this would be like reverting that model.
i can't really imagine how this could be used in a useful, intresting and justifyng way.
Abhinavdecodedthought # Wednesday, March 3, 2010 3:40:00 PM
Martin KadlecBS-Harou # Wednesday, March 3, 2010 4:02:42 PM
Originally posted by jerobarraco:
For Unite Apps and Widgets It's amazing technology and gives us awesome possibilities.
Barraco Mármol Jerónimojerobarraco # Wednesday, March 3, 2010 4:09:18 PM
Originally posted by BS-Harou:
oh, you're right, i totally forgot about them, i was only thinking about webpages..
dahulevogyre # Wednesday, March 3, 2010 4:25:18 PM
It only requires JVM 1.4 or higher.
It's distributed under Apache License 2.0, which is ok for opera i think.
It's light, and more powerful and robust than SQLite.
lucideer # Wednesday, March 3, 2010 4:36:16 PM
Originally posted by jerobarraco:
While they haven't proven to be absolutely massively popular, there are still quite a few people interested in things like "Offline Gmail", and similar apps - they've mostly relied upon Google Gears, but as that's now defunct such things can move to using standardised persistent offline storage like these.
svdb0 # Wednesday, March 3, 2010 5:40:53 PM
I would think that with the whole web being based on XML/SGML derived standards, using an XML database with the existing XPath web standard as a query language would be the obvious choice.
But apparently not. For some unexplained reason, it was decided that the way forward is to add the ill-fitting
SQLSqlite to the web standards.(Another, easier to use way to permanently store data would be through persistent objects. I guess that now that we have getters and setters, this could — and probably will eventually — be implemented in a JavaScript library. But even then, there would be the need for a query language.)
lucideer # Wednesday, March 3, 2010 6:55:21 PM
I must say I agree with everything you've said. Non-SQL DBs are fast coming into the mainstream (CouchDB anyone?) - this seems like a bit of a shortsighted move (certainly not the only one in the HTML5 spec either). However, taking issue with it now is also a bit late given the first draft was almost a year ago.
FransFrenzie # Wednesday, March 3, 2010 8:15:36 PM
Originally posted by svdb0:
XPath is insufficient on its own. XQuery would be fine with me from what I read though (and it essentially supports/includes XPath). In the end I guess it's that millions (including me) already know SQL and "we" don't know XQuery.Haavardhaavard # Thursday, March 4, 2010 7:43:29 AM
Originally posted by jerobarraco:
Caching data so that you can keep working even if your connection drops (for example when on the train, going through a tunnel)? I would actually find that very useful.Keep in mind that more and more people browse on the move. Wireless connections aren't necessarily as stable or reliable as the plug in the wall.
sirnh1 # Thursday, March 4, 2010 8:51:41 AM
(maybe it would also be nice to show the 'allowed quota' for the current site, with the ability to change it)
João EirasxErath # Thursday, March 4, 2010 5:31:17 PM
Originally posted by sirnh1:
Dragonfly does it
Originally posted by sirnh1:
and opera:webstorage and opera:webdatabases do it too
And you're free to touch the file on your hard drive. But be careful with what do you, else you might lose your data.
svdb0 # Thursday, March 4, 2010 8:07:05 PM
Originally posted by lucideer:
This isn't the first time that I've brought this up. About nine months ago I actually asked for the rationale behind the design on the official [a href="http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1174.html"]WHATWG public mailing list[/a]. Noone replied.
While there have apparently be more doubts about this issue, the people who matter (the browser builders) seemed to have decided the issue (individually?) off the list.
I suppose that it's a fait accompli — and kudos to Opera for trying to move the web forward — but that doesn't change the notion that the wrong path has been taken. And so I consider it appropriate to speak out to put this development into perspective.
Cutting Spoonhellspork # Friday, March 5, 2010 4:44:04 AM
sirnh1 # Friday, March 5, 2010 8:46:45 AM
Originally posted by xErath:
Originally posted by xErath:
I know But I thought that it would be nice to have all of that in one place (so
I wouldn'twe wouldn't have to go all over the place to change the settings of a certain site.(I don't really know how the opera:webstorage and opera:webdatabases would look like since none of the sites I regularly visit use it. I already did notice that those 2 still have the old 'opera 9' looks (unlike the opera:about page that has the more modern look))
Leonardo Alassialeoalassia # Wednesday, April 7, 2010 8:04:36 PM
First I've programmed a code to create a table, insert rows and show the selected rows... everything ok... but then I've changed my code to just select the rows and reload the page... it seems like everything was removed, the table hasn't any records, it's suppossed to work like that?
Jan Lundquistjolo1701 # Thursday, May 27, 2010 11:30:42 AM
João EirasxErath # Monday, October 11, 2010 9:22:43 AM
Originally posted by Jan Lundquist:
No, SQLite does not support that. You could try triggers ?