Re: Serializing Asynchronous API calls (was: API patterns and requirements)

Our current approach is close to what Rich proposes -- a second request overrides (and effectively cancels) a first request if the user has not yet consented.  Once the user is into the tab-modal portion of the flow, the Javascript runtime of the page is unable to make a new request.

The Firefox notification system does support the idea of multiple, "stacked" API requests, but we deliberately disabled it because the user experience is messy and confusing.

This approach does tend to encourage developers to request a maximal data set, rather than asking for permission bit-by-bit.  With the current state of the art in browser UI we don't have a great alternative yet.

-Mike



On Jun 17, 2010, at 8:57 AM, Rich Tibbett wrote:

> On Thu, Jun 17, 2010 at 3:42 PM, Dominique Hazael-Massieux <dom@w3.org> wrote:
> 
> Le jeudi 17 juin 2010 à 15:23 +0100, Rich Tibbett a écrit :
> > On the other hand, in order to ensure a reasonable user experience
> > (i.e. don't bombard the user with more than one permission request at
> > a time) I think we should include a requirement for serial access to
> > each API (or collectively, all APIs) - that no more than one API call
> > should be executable concurrently. I'd like to explore if this is a
> > reasonable assumption for e.g. Contacts and whether any changes to the
> > pattern used may be required for this.
> 
> That seems indeed likely a fairly important aspect to look at, thanks
> for bringing it up.
> 
> It makes it slightly more awkward to use as a developer, but I don't
> think to the point of making it painful. And it does seem to solve a
> possibly thorny issue.
> 
> Note that it's not obvious that it should be applied both to Contacts
> and SysInfo — I don't know if the intent is that SysInfo calls would
> require user authorization for each, or just one before the first call,
> or none at all.
> 
> I'd like to know the answer to this. I think this answer affects the API design. My current assumption was that it was per API call, otherwise I'd probably like to request a bunch of system information in a single call if authorization is made just before the first call.
> 
> I wonder how the current Mozilla implementation of the Contacts API deal
> with that aspect — have you looked into it?
> 
> I can't speak for the Mozilla implementation (Mike CCed) but I have included some recommendations to this effect in the current Contacts API draft. The 'find contacts process', 'save contact process' and 'remove contact process' in the spec each begin with the same step 1: "If a current find(), save() or remove() operation is pending a response, invoke the errorCB with a PENDING_OPERATION_ERROR code".
> 
> That provides some normative guidelines for serialized access...though it makes much more sense to enforce such serialization in the API pattern itself if it is possible to do so.
> 
> - Richard
>