[OpenAjaxMobile] Analysis of W3C's latest geolocation APIs and proposals for how to generalize

Paddy Byers paddy.byers at gmail.com
Mon Sep 15 02:11:32 PDT 2008


Hi,

I like the callback idea, in that the API is the same irrespective of
whether the implementation works synchronously or asynchronously. In
principle, any given implementation could elect either to complete
synchronously or asynchronously depending on the circumstances of the
request.

However, in effect this forces all code to be written to expect asynchronous
behaviour, which can end up with things a lot more awkward. For example,
suppose you wanted to do a sequence of things conventionally:

doThis();
doThat();
doTheOther();

With the callback-possibly-asynchronous style of API (if each successive
call depends on results of the previous call) you'd need to do:

doThis(function() {doThat(function() {doTheOther();});});

So what happens when you want to iterate, eg in the conventional style you'd
do:

while(success) {
  success = pim.addContact(contactsToBeAdded[index++]);
}

?

It seems there isn't an obvious analogue - you can write something that is
potentially recursive (if it happens that the addContact API is
synchronous), or you could initiate a series of potentially asynchronous
calls in parallel and wait for all the results to arrive.

I think if a call is known to be either synchronous or known to be
asynchronous it definitely helps to know, and typically user code would be
written one way or another depending on the expected behaviour. I agree it
is neater to capture both types of behaviour in a single style of API, but
you can also argue that the behaviour should be explicit in the form of the
API, if it is defined, to avoid any possible confusion (either on the part
of users of the API or implementers).

Paddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080915/6210bd13/attachment.html 


More information about the mobile mailing list