[whatwg] SQL API and database metadata at creation
beidson at apple.com
Wed Oct 24 10:38:59 PDT 2007
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.
More information about the whatwg