[whatwg] SQL API and database metadata at creation

[Brady Eidson]

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