[IndexedDB] Why rely on run-to-completion?
Can someone explain a bit more about the motivation behind the current design
of the async API?
> var request = window.indexedDB.open(...);
> request.onsuccess = function(event) { ... };
The pattern of assigning the success continuation after invoking the operation
seems to be to closely tied to JavaScript’s current run-to-completion event
handling. But what about future JavaScript environments, e.g. a multi-threaded
Node.js with IndexedDB built in or Rhino with IndexedDB running in parallel?
Wouldn’t a reliance on run-to-completion unnecessarily limit future
developments?
Maybe it is just me, but I would like it better if the last argument was an
object with the error and the success continuations (they could also be
individual arguments). That is also how current JavaScript RPC APIs are
designed, resulting in a familiar look. Are there any arguments *against* this
approach?
Whatever the reasoning behind the design, I think it should be explained in the
spec, because the current API is a bit tricky to understand for newbies.
Thanks!
Axel
--
Dr. Axel Rauschmayer
axel.rauschma...@ifi.lmu.de
http://hypergraphs.de/
### Hyena: organize your ideas, free at hypergraphs.de/hyena/
Re: [IndexedDB] Why rely on run-to-completion?
Right. But is there anything one loses by not relying on it, by making the API
more generic?
On Dec 30, 2010, at 7:58 , Jonas Sicking wrote:
> On Wed, Dec 29, 2010 at 2:44 PM, Axel Rauschmayer wrote:
>> Can someone explain a bit more about the motivation behind the current
>> design of the async API?
>>
>>> var request = window.indexedDB.open(...);
>>> request.onsuccess = function(event) { ... };
>>
>> The pattern of assigning the success continuation after invoking the
>> operation seems to be to closely tied to JavaScript’s current
>> run-to-completion event handling. But what about future JavaScript
>> environments, e.g. a multi-threaded Node.js with IndexedDB built in or Rhino
>> with IndexedDB running in parallel? Wouldn’t a reliance on run-to-completion
>> unnecessarily limit future developments?
>>
>> Maybe it is just me, but I would like it better if the last argument was an
>> object with the error and the success continuations (they could also be
>> individual arguments). That is also how current JavaScript RPC APIs are
>> designed, resulting in a familiar look. Are there any arguments *against*
>> this approach?
>>
>> Whatever the reasoning behind the design, I think it should be explained in
>> the spec, because the current API is a bit tricky to understand for newbies.
>
> Note that almost everyone relies on this anyway. I bet that almost all
> code out there depends on that the code in for example onload handlers
> for XHR requests run after the current thread of execution has fully
> finished.
>
> Asynchronous events isn't something specific to javascript.
>
> / Jonas
>
--
Dr. Axel Rauschmayer
axel.rauschma...@ifi.lmu.de
http://hypergraphs.de/
### Hyena: organize your ideas, free at hypergraphs.de/hyena/
Re: [IndexedDB] Why rely on run-to-completion?
>> The pattern of assigning the success continuation after invoking the
>> operation seems to be to closely tied to JavaScript’s current
>> run-to-completion event handling. But what about future JavaScript
>> environments, e.g. a multi-threaded Node.js with IndexedDB built in or Rhino
>> with IndexedDB running in parallel? Wouldn’t a reliance on run-to-completion
>> unnecessarily limit future developments?
> Could you elaborate on how the current spec would fall-apart without
> run-to-completion semantics? Preferably with specific examples.
See point (3) below.
>> Maybe it is just me, but I would like it better if the last argument was an
>> object with the error and the success continuations (they could also be
>> individual arguments). That is also how current JavaScript RPC APIs are
>> designed, resulting in a familiar look. Are there any arguments *against*
>> this approach?
> Right now we support having multiple callbacks by registering multiple
> listeners for the event (with addEventListener). Using an object would limit
> us to one callback. There is a thread somewhere in this group where we
> decided to go with an event-based API instead of a callback one (I cannot
> recall the reasons off the top of my head).
I'm sorry for coming so late to this discussion, this gives my arguments less
weight and means that I might be rehashing what has already fbeen said. From
what I could find, it was web developers arguing in favor of an event-based
interface. Usually, event-based APIs are structured as follows (with the
only(?) exception of XMLHttpRequest):
- register an event listener at a *fixed* source.
- wait for events being sent from outside. You don’t cause the events, an
external entity (such as the user) does.
This is a bus metaphor and very intuitive, but it does not apply in the case of
APIs and becomes much less intuitive:
(1) *dynamically* create the source of events and cause an event at the same
time
(2) Register the event listeners
(3) Depend on run-to-completion semantics and the event queue to start the
operation. This mixes a user interface queue with a programming API.
Furthermore, one never explicitly starts the operation, only implicitly. I
think the async API is interesting in non-UI contexts (e.g. a future
multi-threaded JavaScript), then you need to explicitly start the operation and
cannot rely on either run-to-completion semantics or the UI event queue
(right?).
I think Ajax RPC APIs are a much better metaphor, instead of the server, you
send requests to IndexedDB. One could also go full-on bus, but with different
invocation sequences that cause the same kinds of events, this would quickly
become ugly.
One additional possibility, that has already been discussed, are futures [1].
If each operation returned a future, then one has the chance of registering
listeners etc. The only thing that would change is an explicit method (such as
run() or get()) to start the operation. I can also imagine a convenience method
run() that takes callbacks.
[1] http://en.wikipedia.org/wiki/Futures_and_promises
For example:
window.indexedDB.open(...)
.addOnSuccess(function() {...})
.addOnFailure(function() {...})
.run();
I wonder if the requirement of multiple listeners for the result (that comes
from web developers) does not unnecessarily mix two concerns: First, invoking
the API. Second, distributing model data to UI components.
>> Whatever the reasoning behind the design, I think it should be explained in
>> the spec, because the current API is a bit tricky to understand for newbies.
> I do not think that a spec is the right place to justify design decisions.
Right. How about a separate document that collects the design rationales? I
find those tremendously useful. They prevent fruitless discussions and the
repetition of mistakes (e.g. in future versions of an API or similar APIs).
To summarize: This API design goes against every non-browser API I have seen
in my 25 years of programming. I expect JavaScript to become *the* mainstream
programming language before long and IndexedDB to play an important role in
that. Thus, staying closer to the mainstream and enabling future extensions is
(IMHO) an important consideration. Going the "futures" route mentioned above
would do that and only require minor changes to the API.
Comments?
Axel
--
Dr. Axel Rauschmayer
axel.rauschma...@ifi.lmu.de
http://hypergraphs.de/
### Hyena: organize your ideas, free at hypergraphs.de/hyena/
Re: [IndexedDB] Why rely on run-to-completion?
I think my main complaint boils down to aesthetics. I don’t expect the event metaphor when I see API invocations, I expect the callback metaphor (used by RPC APIs in Dojo, GWT, etc.). Or, if the event metaphor is used, it has the following clearly delineated stages: (1) Create an event source (2) Register observers/listeners (3) Start event production (3) is implicit and you have to know about the event queue to understand it. I also wonder if multiple listeners ever make sense, don’t they complicate things on the IndexedDB side? Can the same IDB result be read multiple times? I am aware that it is difficult to argue about aesthetics, but given that a few people were already confused about the API (fearing a race condition), a change might make things easier to understand. I can also imagine myself remoting database invocations, RPC-style, if, say, a CouchDB server is currently online and using IndexedDB, otherwise. Having the same API style in both instances would help. On Dec 30, 2010, at 23:43 , Glenn Maynard wrote: > On Thu, Dec 30, 2010 at 5:19 PM, Keean Schupke wrote: >> I think keeping away from multi-threading in JS is sensible (perhaps Erlang >> style multi-processing would be good though). However "interrupting" the >> interpreter to process callbacks is just a single thread and causes no >> problems providing the callbacks are initialised before the call that >> initialises the background process that will generate the asynchronous >> event. > > Delivering events between VM bytecodes is very similar to threading: > it makes code much less deterministic, causing many of the same > problems: race conditions depending on where operations and events > intersect. > > For example, it's very hard in most high-level languages to deal > consistently with asynchronous exceptions: exceptions which can happen > after any bytecode operation. An example is KeyboardInterrupt in > Python. It's very difficult to fully test, and leads to bugs that > are, just like thread races, very hard to reproduce, ultimately > because rather than having a fixed set of branch points to test, you > have as many branches as you have opcodes. > > (By the way, this is why in the synchronous events thread my > suggestion was a function to deliver events, keeping the points where > events can be delivered precisely defined; not something like an > "allow delivery at any time" flag.) > > -- > Glenn Maynard > > -- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ ### Hyena: organize your ideas, free at hypergraphs.de/hyena/
Re: [IndexedDB] Events and requests
;>>>> function(e) {
>>>>>> alert(e.result);
>>>>>> }
>>>>>>
>>>>>> would turn into the slightly more verbose
>>>>>>
>>>>>> db.transaction(["foo"]).objectStore("foo").get(mykey).onsuccess =
>>>>>> function(e) {
>>>>>> alert(e.target.result);
>>>>>> }
>>>>>>
>>>>>> (And note that with the error handling that we have discussed, the
>>>>>> above code snippets are actually plausible (apart from the alert() of
>>>>>> course)).
>>>>>>
>>>>>> The upside that I can see is that we behave more like XMLHttpRequest.
>>>>>> It seems that people currently follow a coding pattern where they
>>>>>> place a request and at some later point hand the request to another
>>>>>> piece of code. At that point the code can either get the result from
>>>>>> the .result property, or install a onload handler and wait for the
>>>>>> result if it isn't yet available.
>>>>>>
>>>>>> However I only have anecdotal evidence that this is a common coding
>>>>>> pattern, so not much to go on.
>>>>>
>>>>> Here's a counter proposal: Let's add .transaction, .source, and .result
>>>>> to IDBEvent and just specify them to be null when there is no transaction,
>>>>> source, and/or result. We then remove readyState from IDBResult as it
>>>>> serves no purpose.
>>>>> What I'm proposing would result in an API that's much more similar to what
>>>>> we have at the moment, but would be a bit different than XHR. It is
>>>>> definitely good to have similar patterns for developers to follow, but I
>>>>> feel as thought the model of IndexedDB is already pretty different from
>>>>> XHR.
>>>>> For example, method calls are supplied parameters and return an
>>>>> IDBRequest
>>>>> object vs you using new to create the XHR object and then making method
>>>>> calls to set it up and then making a method call to start it. In fact, if
>>>>> you think about it, there's really not that much XHR and IndexedDB have in
>>>>> common except that they use event handlers.
>>>>> As for your proposal, let me think about it for a bit and forward it on to
>>>>> some people I know who are playing with IndexedDB already.
>>>>> J
>>>>
>>>
>>>
>>
>
>
--
Dr. Axel Rauschmayer
axel.rauschma...@ifi.lmu.de
http://hypergraphs.de/
### Hyena: organize your ideas, free at hypergraphs.de/hyena/
Re: [IndexedDB] Events and requests
Sicking
> >>>> >>>> wrote:
> >>>> >>>>>
> >>>> >>>>> Hi All,
> >>>> >>>>>
> >>>> >>>>> One of the things we briefly discussed at the summit was that we
> >>>> >>>>> should make IDBErrorEvents have a .transaction. This since we are
> >>>> >>>>> allowing you to place new requests from within error handlers, but
> >>>> >>>>> we
> >>>> >>>>> currently provide no way to get from an error handler to any
> >>>> >>>>> useful
> >>>> >>>>> objects. Instead developers will have to use closures to get to
> >>>> >>>>> the
> >>>> >>>>> transaction or other object stores.
> >>>> >>>>>
> >>>> >>>>> Another thing that is somewhat strange is that we only make the
> >>>> >>>>> result
> >>>> >>>>> available through the success event. There is no way after that to
> >>>> >>>>> get
> >>>> >>>>> it from the request. So instead we use special event interfaces
> >>>> >>>>> with
> >>>> >>>>> supply access to source, transaction and result.
> >>>> >>>>>
> >>>> >>>>> Compare this to how XMLHttpRequests work. Here the result and
> >>>> >>>>> error
> >>>> >>>>> code is available on the request object itself. The 'load' event,
> >>>> >>>>> which is equivalent to our 'success' event didn't supply any
> >>>> >>>>> information until we recently added progress event support. But
> >>>> >>>>> still
> >>>> >>>>> it only supplies information about the progress, not the actual
> >>>> >>>>> value
> >>>> >>>>> itself.
> >>>> >>>>>
> >>>> >>>>> One thing we could do is to move
> >>>> >>>>>
> >>>> >>>>> .source
> >>>> >>>>> .transaction
> >>>> >>>>> .result
> >>>> >>>>> .error
> >>>> >>>>>
> >>>> >>>>> to IDBRequest. Then make "success" and "error" events be simple
> >>>> >>>>> events
> >>>> >>>>> which only implement the Event interface. I.e. we could get rid of
> >>>> >>>>> the
> >>>> >>>>> IDBEvent, IDBSuccessEvent, IDBTransactionEvent and IDBErrorEvent
> >>>> >>>>> interfaces.
> >>>> >>>>>
> >>>> >>>>> We'd still have to keep IDBVersionChangeEvent, but it can inherit
> >>>> >>>>> Event directly.
> >>>> >>>>>
> >>>> >>>>> The request created from IDBFactory.open would return a IDBRequest
> >>>> >>>>> where .transaction and .source is null. We already fire a IDBEvent
> >>>> >>>>> where .source is null (actually, the spec currently doesn't define
> >>>> >>>>> what the source should be I see now).
> >>>> >>>>>
> >>>> >>>>>
> >>>> >>>>> The only major downside with this setup that I can see is that the
> >>>> >>>>> current syntax:
> >>>> >>>>>
> >>>> >>>>> db.transaction(["foo"]).objectStore("foo").get(mykey).onsuccess =
> >>>> >>>>> function(e) {
> >>>> >>>>> alert(e.result);
> >>>> >>>>> }
> >>>> >>>>>
> >>>> >>>>> would turn into the slightly more verbose
> >>>> >>>>>
> >>>> >>>>> db.transaction(["foo"]).objectStore("foo").get(mykey).onsuccess =
> >>>> >>>>> function(e) {
> >>>> >>>>> alert(e.target.result);
> >>>> >>>>> }
> >>>> >>>>>
> >>>> >>>>> (And note that with the error handling that we have discussed, the
> >>>> >>>>> above code snippets are actually plausible (apart from the alert()
> >>>> >>>>> of
> >>>> >>>>> course)).
> >>>> >>>>>
> >>>> >>>>> The upside that I can see is that we behave more like
> >>>> >>>>> XMLHttpRequest.
> >>>> >>>>> It seems that people currently follow a coding pattern where they
> >>>> >>>>> place a request and at some later point hand the request to
> >>>> >>>>> another
> >>>> >>>>> piece of code. At that point the code can either get the result
> >>>> >>>>> from
> >>>> >>>>> the .result property, or install a onload handler and wait for the
> >>>> >>>>> result if it isn't yet available.
> >>>> >>>>>
> >>>> >>>>> However I only have anecdotal evidence that this is a common
> >>>> >>>>> coding
> >>>> >>>>> pattern, so not much to go on.
> >>>> >>>>
> >>>> >>>> Here's a counter proposal: Let's add .transaction, .source, and
> >>>> >>>> .result
> >>>> >>>> to IDBEvent and just specify them to be null when there is no
> >>>> >>>> transaction,
> >>>> >>>> source, and/or result. We then remove readyState from IDBResult as
> >>>> >>>> it
> >>>> >>>> serves no purpose.
> >>>> >>>> What I'm proposing would result in an API that's much more similar
> >>>> >>>> to what
> >>>> >>>> we have at the moment, but would be a bit different than XHR. It
> >>>> >>>> is
> >>>> >>>> definitely good to have similar patterns for developers to follow,
> >>>> >>>> but I
> >>>> >>>> feel as thought the model of IndexedDB is already pretty different
> >>>> >>>> from XHR.
> >>>> >>>> For example, method calls are supplied parameters and return an
> >>>> >>>> IDBRequest
> >>>> >>>> object vs you using new to create the XHR object and then making
> >>>> >>>> method
> >>>> >>>> calls to set it up and then making a method call to start it. In
> >>>> >>>> fact, if
> >>>> >>>> you think about it, there's really not that much XHR and IndexedDB
> >>>> >>>> have in
> >>>> >>>> common except that they use event handlers.
> >>>> >>>> As for your proposal, let me think about it for a bit and forward
> >>>> >>>> it on to
> >>>> >>>> some people I know who are playing with IndexedDB already.
> >>>> >>>> J
> >>>> >>>
> >>>> >>
> >>>> >>
> >>>> >
> >>>>
> >>>
> >>
> >
> >
>
--
Dr. Axel Rauschmayer
axel.rauschma...@ifi.lmu.de
http://hypergraphs.de/
### Hyena: organize your ideas, free at hypergraphs.de/hyena/
Re: [IndexedDB] Events and requests
Looks great, I just tried to stay as close to the current API as possible.
A single handler should definitely be enough. Can, say, a cursor be read
multiple times (if there are several success handlers)? Doesn’t that make
things more complicated?
On Jan 11, 2011, at 10:22 , Keean Schupke wrote:
> Comments inline:
>
> On 11 January 2011 07:11, Axel Rauschmayer wrote:
> Coming back to the initial message in this thread (at the very bottom):
> => General rule of thumb: clearly separate input data and output data.
>
> Using JavaScript dynamic nature, things could look as follows:
>
> indexedDB.open('AddressBook', 'Address Book', {
> success: function(evt) {
> },
> error: function(evt) {
> }
> });
>
> Personally I prefer a single callback passed an object.
>
> indexedDB.open('AddressBook', 'Address Book', function(event) {
> switch(event.status) {
> case EVENT_SUCCESS:
> break;
> case EVENT_ERROR:
> break;
> }
> });
>
> As it allows callbacks to be composed more easily.
>
> - The last argument is thus the request and clearly input.
>
> - If multiple success handlers are needed, success could be an array of
> functions (same for error handlers).
>
> multiple handlers can be passes using a composition function:
>
> // can be defined in the library
> var all = function(flist) {
>return function(event) {
>for (int i = 0; i < flist.length; i++) {
>flist[i](event);
>}
> };
> };
>
> indexedDB.open('AddressBook', 'Address Book', all([fn1, fn2, fn3]));
>
>
> Cheers,
> Keean.
>
>
>
> - I would eliminiate readyState and move abort() to IDBEvent (=output and an
> interface to the DB client).
>
> - With subclasses of IDBEvent one has the choice of eliminating them by
> making their fields additional parameters of success() and error().
> event.result is a prime candidate for this!
>
> - This above way eliminates the need of manipulating the request *after* (a
> reference to) it has been placed in the event queue.
>
> Questions:
>
> - Is it really necessary to make IDBEvent a subclass of Event and thus drag
> the DOM (which seems to be universally hated) into IndexedDB?
>
> - Are there any other asynchronous DB APIs for dynamic languages that one
> could learn from (especially from mistakes that they have made)? They must
> have design principles and rationales one might be able to use. WebDatabase
> (minus schema plus cursor) looks nice.
>
> On Jan 10, 2011, at 23:40 , Keean Schupke wrote:
>
>> Hi,
>>
>> I did say it was for fun! If you think it should be suggested somewhere I
>> am happy to do so. Note that I renamed 'onsuccess' to 'bind' to show how it
>> works as a monad, there is no need to do this (although I prefer to it to
>> explicitly show it is a Monad).
>>
>> The definition of unit is simply:
>>
>> var unit = function(v) {
>> return {
>> onsuccess: function(f) {f(v);}
>> };
>> };
>>
>> And then you can compose callbacks using 'onsuccess'...
>>
>> you might like to keep onsuccess, and use "result" instead of "unit"... So
>> simply using the above definition you can compose callbacks:
>>
>> var y =
>> db.transaction(["foo"]).objectStore("foo").getM(mykey1).onsuccess(function(result1)
>> {
>>
>> db.transaction(["foo"]).objectStore("foo").getM(mykey2).onsuccess(function(result2)
>> {
>> result(result1 + result2);
>> });
>> });
>>
>>
>> Cheers,
>> Keean.
>>
>>
>> On 10 January 2011 22:31, Jonas Sicking wrote:
>> This seems like something better suggeseted to the lists at ECMA where
>> javascript (or rather ECMAScript) is being standardized. I hardly
>> think that a database API like indexedDB is the place to redefine how
>> javascript should handle asynchronous programming.
>>
>> / Jonas
>>
>> On Mon, Jan 10, 2011 at 2:26 PM, Keean Schupke wrote:
>> > Just to correct my cut and paste error, that was of course supposed to be:
>> > var y = do {
>> > result1 <- db.transaction(["foo"]).objectStore("foo").getM(mykey1);
>> > result2 <- db.transaction(["foo"]).objectStore("foo").getM(mykey2);
>> > unit(result1 + result2);
>> > }
>> >
>> > Cheers,
>> >
Bug reports from jessica.w3.org?
Why do we get these? Could we have opt-in and not send them to the mailing list (at least the majority of them which seems to contain nonsense)? Thanks! Axel -- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ ### Hyena: organize your ideas, free at hypergraphs.de/hyena/
Re: An HTML5 logo
Yes, the logo looks awesome! But I think we should clarify who the logo is for: Techies or end users. All the logo mission statements that I have read point to the former group, but I think it makes more sense to target the latter group. Then HTML5 might not be a good brand [1]. [1] http://www.2ality.com/2011/01/branding-web-technologies-and-new-html5.html On Jan 23, 2011, at 4:49 , Marcos Caceres wrote: > Hi Philippe, > > Logos look nice! however, I'm baffled as to why HTML5 logo site mix in > things like WebGL and CSS 3, which are clearly not part of the HTML > Standard (as it is now known;))? Who made the choice of what > technologes were to be included or excluded from the set of > technologies that make up the logo sets? I ask because it's poignant > and a little demoralizing to us who have been working for many years > to see W3C Widgets excluded from the list. I'm sure I'm not the only > one feeling a bit confused by the W3C's lack of communication about > this project or why the W3C chose to exclude widgets and other > technologies? Did I miss the memo? > > Kind regards, > Marcos > > On Tue, Jan 18, 2011 at 2:03 PM, Philippe Le Hegaret wrote: >> Dear Web Application Working Group, >> >> Today W3C introduced an HTML5 logo for public consideration: >> http://www.w3.org/News/2011#entry-8992 >> >> The W3C Communications Team is excited about the HTML5 logo, developed >> with community support, and hopes it will help you promote your work. >> The logo is intended to be a general purpose visual identity for HTML5 >> and other web application technologies. It doesn't imply conformance; >> just "this is about open web application technologies." >> >> This is not yet the official W3C Communications Team logo for HTML5. We >> look forward to broad community adoption in order to make it so. >> >> For more information about the logo, see the logo home page [1] and faq >> [2]. >> >> Thank you, >> >> Philippe Le Hégaret, Interaction Domain Lead >> >> [1] http://www.w3.org/html/logo/ >> [2] http://www.w3.org/html/logo/faq >> >> >> >> > > > > -- > Marcos Caceres > Opera Software ASA, http://www.opera.com/ > http://datadriven.com.au > > -- Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
I am really sorry to bring this up again, but: Why not separate concerns? Why
not separate input data and output data?
If onsuccess and onerror were handed in as an input parameters, would there be
any need for readyState, LOADING, and DONE? Then IDBRequest would be more like
an event, right? It would be sent to the onsuccess and onerror event handlers.
> Actually, I was proposing something entirely different.
>
> IDBRequest should look like this:
>
> interface IDBRequest : EventTarget {
>attribute any result;
>attribute unsigned long errorCode;
>attribute DOMObject source;
>attribute IDBTransaction transaction;
>
>const unsigned short LOADING = 1;
>const unsigned short DONE = 2;
>readonly attribute unsigned short readyState;
>
> attribute Function onsuccess;
> attribute Function onerror;
> };
>
> "success" and "error" events are plain Event objects, i.e. no
> indexedDB-specific properties.
>
> The advantage of this is:
> 1. Request objects are actually useful as representing the request.
> Consumers of a request can check what the readystate is and either get
> the .result or attach a event listener as appropriate. (As things
> stand now you can't really rely on .readyState. The only thing it
> tells you is if you got to the request too late or not. If you risk
> getting there too late you better rewrite your code)
> 2. Easier to implement a promises-style API on top of indexedDB.
> 3. More similar to for example XMLHttpRequest
>
> The downside is:
> 1. Have to use a bigger syntax to get to the result. "event.result"
> vs. "event.target.result".
>
> / Jonas
>
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
Home: http://rauschma.de
Blog: http://2ality.com
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
> I'm still not convinced this use case is necessary either, but we've already > argued that to death, so let's not start up again. Agreed. My only aside would be that for API design, it’s usually not a good idea to listen to web developers, but to someone who has experience with designing DB APIs (= not me, but possibly anyone of you or anyone at Mozilla, MS, Google). -- Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
> Also note that the reason that your suggestion removes the need for > readyState is that your proposal decides to drop support for the > use-case that readyState aims to help solve. I.e. the ability to > register additional event handlers sometime after the request is > created. All API invocations that I have seen relied on run-to-completion semantics and add a listener after the initial invocation. These now have to check the flag? Note that one can create the event emitter (and register handlers) before invoking an operation. > >> Then IDBRequest would be more like an event, right? It would be sent to the >> onsuccess and onerror event handlers. > > I don't understand what you mean here. But in the current model (both > the one that's in the spec right now, and the one that I'm proposing) > we're using real DOM-Events. Can't really get more "like events" than > that? Right, I’m sorry. I was confused, because IDBRequest plays double duty. To me an event is something that is created at the event emitter and directly sent to event handlers, without exposing it inbetween. That is too narror and IDBRequest is indeed an event. -- Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
>> Agreed. My only aside would be that for API design, it’s usually not a good >> idea to listen to web developers, but to someone who has experience with >> designing DB APIs (= not me, but possibly anyone of you or anyone at >> Mozilla, MS, Google). > It sounds like you are saying we aren't listening to people who have designed > database APIs. We certainly have (and have borrowed from models of existing > APIs for other databases too). I hope I was and am sounding constructive, I really appreciate the hard work that went into IndexedDB and am trying to understand the design rationales. So far I have used APIs for JDBC, WebDatabase, RDF, and CouchDB. And they all seemed similar in the patterns they used (how functionality was invoked etc.). I was wondering why IndexedDB was so different. Until now, I have only seen events in bus-like constructs (Node.js event emitters, DOM events for DOM elements, custom DOM events for a complete web page, etc.). -- Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com
