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

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