- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Fri, 8 Mar 2013 14:27:50 -0800
- 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 handlers. 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. http://terrainformatica.com
Received on Friday, 8 March 2013 22:28:22 UTC