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

Re: Persistent Storage vs. Database

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 8 Mar 2013 14:27:50 -0800
Message-ID: <CALRQH78F4Unzq8wthbLA=hQxb_dCukVdmhG3HhAAS1V5RphYGQ@mail.gmail.com>
To: Kyle Huey <me@kylehuey.com>
Cc: public-webapps <public-webapps@w3.org>
On Fri, Mar 8, 2013 at 11:30 AM, Kyle Huey <me@kylehuey.com> wrote:
> On Fri, Mar 8, 2013 at 11:02 AM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> On Thu, Mar 7, 2013 at 10:36 PM, Kyle Huey <me@kylehuey.com> wrote:
>> > On Thu, Mar 7, 2013 at 10:20 PM, Andrew Fedoniouk
>> > <news@terrainformatica.com> wrote:
>> >
>> >> At least it is easier than http://www.w3.org/TR/IndexedDB/ :)
>> >
>> >
>> > Easier doesn't necessarily mean better.  LocalStorage is certainly
>> > easier to
>> > use than any async storage system ;-)
>> >
>> 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.
> That's not true at all.  If you don't understand the difference between
> finalizers and events you're not going to be able to make a very informed
> criticism of IndexedDB.

I would appreciate if you will define term `event`. After that we can discuss
it further.

As of common practice there are two types so called outbound calls:
1. Synchronous *callbacks* that are not strictly speaking events - just function
   references: "after/before-doing-this-call-that". 'finalized' is
that kind of callback.
2. Events - these are objects and event dispatching system associated
   with them. For example UI events use capture/bubble dispatching
   system and event queue. Events operate independently from their

Let's take a look on this example from IndexedDB spec:

var request = indexedDB.open('AddressBook', 15);
 request.onsuccess = function(evt) {...};
 request.onerror = function(evt) {...};

It looks *very* wrong to me:

What should happen if db.open() will open the DB immediately?
Will request.onsuccess be called in this case?
If indexedDB.open is purely async operation then
why it has to be exactly async? What may take time there other
than opening local file in worst case? If that request is async then
when precisely request.onsuccess will be called?

I would understand if DB.open call will be defined this way:

function onsuccess(evt) {...};
function onerror(evt) {...};

var request = indexedDB.open('AddressBook', 15, onsuccess, onerror );

(so pure callback operation).

But purpose of such event-aganza is still not clear to me.

Why not classical:

try {
  request = indexedDB.open('AddressBook', 15 );
} catch(err) { ... }


In principle: what are operations in IndexedDB that may
take so long time that they need to be async?

Size of client side DB has and will always have some
reasonable cap limiting its size and so any lookup or
update operation in indexed DB will take some finite
and *very* short time (if to compare with the time needed
to relayout average page).

Why these so strange "events" are there at all?
And so why all this has to be that complex?

Andrew Fedoniouk.

Received on Friday, 8 March 2013 22:28:22 UTC

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