[trying again with the right e-mail, sorry for the dupes...]
On Thu, Jul 12, 2012 at 12:38 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Thu, Jul 12, 2012 at 2:07 AM, Yuval Sadan <sadan.yu...@gmail.com>
> wrote:
> >> I think we need to realize that a lot of the APIs that have been
> >> designed in the past aren't terribly good APIs.
> >
> > The IndexedDB API is rather new, and the manner in which it consistently
> > uses event handlers on returned objects is rather innovative. The
> > DOMTransaction object is more similar to that.
>
>
The IndexedDB pattern is rather an old one - see the Python (I know,
Ryosuke....) "Twisted" library which uses 'deferreds' which went on to
influence hundreds of projects in many languages. Eventually it migrated
into JS libraries as "promises" (sans a few subtle differences...)
I think the key difference between the two models (DOMTransaction vs
IndexedDB's events) is about the creation of the event-owning object. hen
you pass in a dictionary/DOMTransaction/etc, then the caller is is
responsible for creating that object and doesn't give the callee (i.e. the
API) a lot of control over the event propagation/etc. One thing IndexedDB's
IDBRequest object has going for it is that the implementation creates it,
therefore controls the behavior and the interaction between success, error,
and abort events.
One particularly nice thing the event pattern adds on top of the deferred
pattern is the ability to have multiple semantically parallel event
handlers, i.e.
// wrapper around get() to update something whenever we encounter purple
keys
function myGet(k) {
r = objectStore.get(k)
r.addEventListener(dealWithPurpleKeys);
return r;
}
r = myGet(key);
r.addEventListener(dealWithThisKey);
If the DOMTransaction/dictionary has to be passed in, this complicates this
pattern quite a bit, and this is a pretty nice pattern in a dynamic
language like JS.
In IndexedDB events work out "ok" since we can take advantage of the
> event bubbling mechanism. That's not the case here.
>
> Likewise, in IndexedDB you generally only have to install a single
> event handler, which means that you can write code like:
> store.get(...).onsuccess = function(event) { ... };
>
>
I would argue that you can do this easily in IndexedDB *because* of event
bubbling - or at least by the fact that there is a "parent" object (the
IDBTransaction) - you can let error propagation be handled by a "parent"
object so that you dont' have to install error handlers on every request.
Just watching this conversation, the way I'm seeing it is it's fairly easy
to make a wrapper API around the deferred/event model that looks like
Ryosuke's model, than it is the other way around. It also seems like if you
could add some kind of event handling (i.e. if a user had a kind of generic
undo-er method that worked on 90% of events, but then could attach specific
undoer-s to specific types of transactions)
(I personally come from the school of thought that the DOM APIs are kind of
the assembly language of the web - they're very powerful and exact, you can
use them in a pinch but most people won't use them directly and will put
some kind of higher level abstraction on top of them. I don't think this is
a failing of the APIs by any means, no more than the proliferation of
computer languages is a failing of CPUs)
> Alec
