Re: API patterns and requirements

On Wed, Jun 23, 2010 at 11:09 AM, Robin Berjon <robin@robineko.com> wrote:

> On Jun 17, 2010, at 16:23 , Rich Tibbett wrote:
> > The following pattern, as used in the IndexedDB specification [1], would
> be applied to System-Info and Contacts APIs:
> >
> > SystemInfo API example:
> >
> > navigator.system.request.onsuccess = function() {
> >     var batteries = navigator.system.request.result;
> >     for(i in batteries) alert(batteries[i].level);
> > };
> > navigator.system.get('Power');
>
> Access serialisation is a valid concern, but solving it with global
> handlers is the wrong solution. The solution you propose means that all code
> that needs to access the API will need to coordinate with one another so as
> to avoid overwriting, and that a single faulty library can break it for
> everyone. Not good. It's a very common issue with window.onload — I'd really
> rather we learnt from that mistake.
>

Yep, I came to the same conclusion :-(. Serial access is useful but it
should not come at the expense of having to chain requests to one another.
If one breaks, everything breaks. I'm looking in to other solutions.



>
> I like Mike's suggestion of aborting the previous request. It's simple,
> it's what XHR does, it can be described rather easily.
>
>
Right. In the current spec it's FIFO (where subsequent requests throw an
error) rather than Mike's suggestion of LIFO (where previous requests throw
an error).

With a FIFO model, I'd be able to queue subsequent requests using some e.g.
JS Polling: keep trying the subsequent requests and if
PENDING_OPERATION_ERROR is thrown, continue polling and wait for first
request to be completed or for the first request to timeout.

With a LIFO model, the first few callbacks would throw a TIMEOUT_ERROR(?).
So any success callback code associated to these previous requests would
never be run?


- Richard