[whatwg] SQL API and database metadata at creation

Mon Nov 12 10:48:45 PST 2007

On Nov 12, 2007, at 10:29 AM, Aaron Boodman wrote:

> On 10/31/07, Ian Hickson <ian at hixie.ch> wrote:
>> I agree, but like you I don't know exactly what to say about this.  
>> This is
>> an area where implementation experience will help. It may be, for
>> instance, that nobody uses more than one database per app, and a  
>> prompt
>> ends up being fine.
>
> I think one simple way to address this is to move the metadata into
> the application itself. For example:
>
> <html applicationName="Google Reader">
>
> You can imagine other things eventually going in to this application
> metadata, such as icons at various sizes.

Good idea, but I don't think it solves the same problem.  The "Display  
Name" user readable description is per database.  Specific web page/ 
apps can have an arbitrary number of databases, in addition to the  
possible collisions introduced by databases being per origin.

> I also think the estimated bytes thing is not that useful. It's going
> to be hard for developers to estimate this and they're all just going
> to but 64k or something they copied from an example.

I agree for many apps it will be hard to estimate this, but not all.
Whereas some apps will store arbitrary amounts of user data, others  
will just want a small amount of persistent storage client side for  
prefs/settings. and others still will know they are going to store  
50mb of app data client side.

> I think it should be up to the UA to make sure that the database does
> not grow "too large" and to prompt the user for access to more storage
> when necessary on behalf of the application.

Obviously all UA's should do this.  The expected size is more of a UI  
hint than a contract.  UA's should still do what they need to do.

The value of these arguments might end up being somewhat dubious, but  
I requested they be added based on implementation experience -  
noticing some holes left but the info available in the previous  
iterations of the spec.

I would not be against making the "expected size" optional, but I am a  
firm believer in the display name.

~Brady