Re: [Bug 11350] New: [IndexedDB] ObjectStores should have a way to hint that they're "evictable"

On Fri, Nov 19, 2010 at 12:05 PM, <bugzilla@jessica.w3.org> wrote:

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11350
>
>           Summary: [IndexedDB] ObjectStores should have a way to hint
>                    that they're "evictable"
>           Product: WebAppsWG
>           Version: unspecified
>          Platform: PC
>        OS/Version: All
>            Status: NEW
>          Severity: normal
>          Priority: P2
>         Component: Indexed Database API
>        AssignedTo: dave.null@w3.org
>        ReportedBy: jorlow@chromium.org
>         QAContact: member-webapi-cvs@w3.org
>                CC: mike@w3.org, public-webapps@w3.org
>
>
> At TPAC, we talked about whether we should make some way for web apps to
> tell
> the UA that data is not critical.  Many uses for IndexedDB are such that
> it's
> not a big deal if data is discarded, but there are some use cases where
> it's
> critical.  For example, the archive of your email for all time might not be
> critical, but the email you wrote while offline that still hasn't gotten a
> chance to send yet is.
>
> We discussed what the proper granularity is.  Per record seems very
> difficult
> to implement efficiently.  Per database means that you can't have
> transactions
> that involve both both classes of data.  So we decided to make it
> per-objectStore.
>
> createObjectStore's optional parameters will turn into a single optional
> options object that gets passed in.  So, for example, you would do
> .createObjectStore("name", {autoIncrement: true, keyPath: "id"}); to create
> an
> objectStore with an autoIncrement number stored in the id keyPath and the
> name
> of "name".
>
> We'll then add another parameter to the optional options object parameter
> that
> is "evictable" which states whether or not the browser can get rid of the
> data
> at its discretion.  This will default to false.
>
> --
> Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
>
Another related item that we never finished discussing: should we provided
any way for web apps to hint at how big the database will be.

Pros:
* Users can make more informed decisions
* Browsers can limit the number of popups asking the users if they want to
allow the database to grow

Cons:
* The size is an implementation detail that will vary from UA to UA
* Web apps might not be very good at anticipating their needs
* Most people seem to feel the estimated size param of SQLDB is fairly
worthless.

J