On Nov 12, 2007, at 10:29 AM, Aaron Boodman wrote:
On 10/31/07, Ian Hickson <[EMAIL PROTECTED]> 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
