- From: Rob Kroeger <rjkroege@liqui.org>
- Date: Sat, 29 Aug 2009 09:55:36 -0400
Hi, On Saturday, August 29, 2009, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 13 Aug 2009, Rob Kroeger wrote: >> > >> >From http://dev.w3.org/html5/webdatabase/: >> >> "The openDatabase() method on the Window and WorkerUtils interfaces must >> return a newly constructed Database object that represents the database >> requested." >> >> The spec does not make it clear what the UA on an extremely >> resource-constrained device (e.g. a mobile phone) should do if the >> requested size database size cannot be satisfied. Some implementations >> return a null Database object if something has gone wrong in the >> openDatabase() call but (at least to me) the spec does not seem to >> permit this and simply returning null does not particularly help an >> application adapt gracefully to the availability of only a small >> database. >> >> Consequently, I would hope that this could be improved in some fashion. >> Three possible modifications to the spec occur to me. From the viewpoint >> of webdatabase developer, I prefer (1), could work with (2) and would >> greatly dislike (3). Is this reasonable? >> >> 1. Retain the existing def'n of openDatabase but add a property on >> interface Database: >> ? unsigned long minimumCapacity; >> which returns the amount of storage that the UA guarantees to be >> present in the database at the time of opening. The UA should try to >> set minimumCapacity so that QUOTA_ERR will be extremely unlikely if >> the database client code never writes more than minimumCapacity bytes >> to the database. >> >> 2. A language change: >> >> "The user agent may raise a SECURITY_ERR exception instead of >> returning a Database object if the request violates a policy decision >> (e.g. if the user agent is configured to not allow the page to open >> databases)." >> >> to something like this: >> >> "The user agent must raise a SECURITY_ERR exception instead of >> returning a Database object if the request violates a policy decision >> (e.g. if the user agent is configured to not allow the page to open >> databases) or the estimatedSize of the database cannot currently be >> satisfied (e.g. the UA is running from a read-only volume or the >> estimatedSize exceeds the free space on the volume.)" >> >> 3. An alternative language change: >> >> "The openDatabase() method on the Window and WorkerUtils interfaces >> must return a newly constructed Database object that represents the >> database requested." >> >> to >> >> "The openDatabase() method on the Window and WorkerUtils interfaces >> must return a newly constructed Database object that represents the >> database requested or null if openDatabase call has failed." > > Technically, a UA is allowed to do more or less whatever it wants when > faced with hardware limitations. > > However, a literal reading of the spec says it should return a Database, > and then if writing to it fails due to lack of disk space, should throw or > flag the QUOTA_ERR. Why is this not adequate? It makes it extremely difficult to build an application that both starts up quickly and operates reliably. Consider a mobile web application for reading email (Gmail for Mobile for example) where the database caches email locally. Startup on a cellular network proceeds roughly like this: 1. load the app from the Application cache 2. create the Database object 3. query the Database for some email 4. (Ideally) do some app work while waiting for the statement callback 5. display some email on the screen 6. request new emails from the server 7. interact with the user... 8.1 persist user changes to the database 8.2 receive new email from the server and write that into the database The user perceives the app's startup time to be steps 1 through 5. But with notification on QUOTA_ERR, the app only knows if it has a fully functioning database several seconds after step 5 at the unsuccessful conclusion of step 8.1 or 8.2. Several choices exist to handle this: * insert 2.1: write to the database and 2.2: get the success callback so that the app can adjust itself early for not having a working database. This works but adds several hundred ms to the time of 1..5 on a mobile phone. * fail at 8.1 and relaunch the app in no-database mode. This is easy to implement correctly but users greatly dislike losing changes from step 7. At the frequency of occurrence of filling up the disk on a desktop, this would be a perfectly fine solution. At the frequency of occurrence of filling up the storage on an under-resourced mobile phone, it is not a fine solution. * Seamlessly switch at state 8.1 to no-database mode. Experience has shown that this is frustratingly hard get right in real implementations and still cannot guarantee saving user changes from step 7 if the network has failed. So, mostly what I'm requesting is that the UA provide some feedback as early as possible (at stage 2 say) that makes a "highly likely" promise of how much space is available in the database so that the app can extend a similarly likely promise to its users that the app will operate correctly with or without a network connection. For what it's worth, I believe that the option (1) choice of minimumCapacity in my original email would be quite easy to implement on WebKit for iPhone and Safari UAs: just return 5MB. Rob. > > -- > Ian Hickson ? ? ? ? ? ? ? U+1047E ? ? ? ? ? ? ? ?)\._.,--....,'``. ? ?fL > http://ln.hixie.ch/ ? ? ? U+263A ? ? ? ? ? ? ? ?/, ? _.. \ ? _\ ?;`._ ,. > Things that are impossible just take longer. ? `._.-(,_..'--(,_..'`-.;.' > -- Rob Kroeger rjkroege at liqui.org http://www.liqui.org
Received on Saturday, 29 August 2009 06:55:36 UTC