- From: Brady Eidson <beidson@apple.com>
- Date: Wed, 24 Oct 2007 10:38:59 -0700
First off, my first impression of the new API is that I like it a lot and think it addresses most - if not all - of the outstanding issues. We'll see if that impression continues after I process it all! =D --------------------- On to my point... The API has various places where the User Agent should provide some form of UI for policy and management of databases. For example if an origin reaches its size limit, the User Agent should prompt for permission to exceed the limit. Additionally, the UA is required to provide a facility for the user to see the size of all current databases. Google Gears takes things further by prompting the user for permission to create a database in the first place. I think this is quite prudent and we're likely to provide facilities for the same prompt. The problem I have is that all of these UI elements - required or prudent - have little to work with for making the UI clear and useful. In the wild, database names will often not be too useful. We use "WebKitStickyNotes" for our example, but someone might use a generic "Database" or a cyrptic "__rvWidgets" as a database name. How is a user supposed to interpret that in the management UI? It is unlikely to be useful or meaningful. And if a UA prompts the user at creation like Gears, how is the user supposed to make a meaningful decision if they're told "www.foobar.com wants to create a database named '__Xlak`"? The database name is - and should remain - a technical detail that is internal to the implementation of a web application. I propose we provide an optional way for an openDatabase() call to include a DatabaseDescription, which is meant to be a human-readable name or description of the database. This would make policy prompts regarding the database (creation, increasing the size) as well as the management UI potentially more meaningful and clear to the user. A side proprosal that might help consolidate the "should I allow this database to be created?" and "should this origin be allowed to go over its size limit?" prompts would be to provide another optional argument to the openDatabase() call which is the "expected size of the database" which is something many application developers may be able to establish ahead of time. Armed with these two option arguments, a single UI prompt similar to: "www.google.com wants to create a database on your hard drive. The purpose of the database is for "<DatabaseDescription>" and www.google.com thinks the database might use up to <expected size> bytes of drive space. Do you want to let it continue?" The response to this prompt could remove the requirement to bump the allowed quota later as long as the database stays under its expected usage. The DatabaseDescription and allowed size could also be represented in the management UI. Armed with the current information, the prompt could only be: "www.google.com wants to create a database named <cryptic name> on your hard drive. Do you want to let it continue?" I don't think this is mission critical for the spec. But I do think that as long as there are required UI elements in the spec as well as implicit UI elements many User Agents will choose to implement, that the spec would be even more proficient to have a standard way to provide this information. ~Brady
Received on Wednesday, 24 October 2007 10:38:59 UTC