W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Persistent Storage vs. Database

From: Glenn Maynard <glenn@zewt.org>
Date: Fri, 8 Mar 2013 17:27:21 -0600
Message-ID: <CABirCh-Rn5P-QbCi324tCcvSszgdpAajZjTAcAhcbHgF2nsCmQ@mail.gmail.com>
To: Kyle Huey <me@kylehuey.com>
Cc: Andrew Fedoniouk <news@terrainformatica.com>, public-webapps <public-webapps@w3.org>
On Fri, Mar 8, 2013 at 12:36 AM, Kyle Huey <me@kylehuey.com> wrote:

> On Thu, Mar 7, 2013 at 10:20 PM, Andrew Fedoniouk <
> news@terrainformatica.com> wrote:
>> Physical commit (write) of objects to storage happens on either
>> a) GC cycle or b) on explicit storage.commit() call or on c) VM shutdown.
> Persisting data off a GC cycle (via finalizers or something else) is a
> pretty well known antipattern.[0]

Correct, but just to be clear, there are other ways to get a similar
effect.  In particular, you can queue a task, add a job to the "global
script clean-up jobs" list, or use a microtask.

At least it is easier than http://www.w3.org/TR/IndexedDB/ :)
Note that if you see "TR" in a URL, you're probably looking at an old,
obsolete spec.  This one is almost a year out of date.  Click the "editor's
draft" link at the top to get to the real spec.

On Fri, Mar 8, 2013 at 1:02 PM, Andrew Fedoniouk

> At least my implementation does not use any events. Proposed
> system of events in IndexedDB is the antipattern indeed. Exactly for
> the same reasons as finalizer *events* you've mentioned above - there
> is no guarantee that all events will be delivered to the code awaiting
> and relaying on them.

This is wrong.  Events are not an "antipattern" (calling things that seems
a bit of a fad these days), and they're certainly not a "proposal".  It's
the standard, well-established API on the Web, used broadly across the
whole platform.

Glenn Maynard
Received on Friday, 8 March 2013 23:27:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:59 UTC