[OpenAjaxMobile] Reminder: Conf call information
Andrew Sledd
Andrew.Sledd at ikivo.com
Thu Sep 25 05:38:21 PDT 2008
Thanks Rotan.
We will review your comments briefly during the call.
Andy
________________________________
From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Rotan Hanrahan
Sent: den 25 september 2008 13:45
To: OpenAjax Alliance discussion list on Mobile Ajax
Subject: Re: [OpenAjaxMobile] Reminder: Conf call information
Regarding checking Jon's draft against existing JavaScript APIs, the
draft geolocation API is not the only kid on the block. (The Geolocation
group is now formally calling for participants, so we can expect "real"
work to commence soon.) Anyway, there are a few other APIs that you can
take a look at, such as these two:
Selectors API
http://dev.w3.org/2006/webapi/selectors-api/
DCCI (which binds to JavaScript, among other things)
http://www.w3.org/TR/DPF/
In many cases, APIs intended for widespread use beyond a single
implementation language are specified in (some flavour of) IDL. To see
if these APIs are available in JavaScript you'll need to search for
implementation reports. For the moment, the evolving geolocation API has
JavaScript in mind as the target implementation environment, but it
would not surprise me if some generalisations were to creep in. The
Widgets API is also being positioned for use with JavaScript
(ECMAScript) http://www.w3.org/TR/2007/WD-widgets-reqs-20070705/
As it's now almost certain that I won't be able to attend today's call,
I'll give here a few of my comments on Jon's first draft.
* Separate the guidelines from any specific evaluation of an
API. This means take the geolocation material out to a separate page.
* To facilitate the above, give every guideline a unique code. I
recommend that you adopt the approach used by the MWI Best Practices
group. See this: http://www.w3.org/TR/mobile-bp/
* I very much approve of the high-level items (Simplicity,
Directness, Consistency etc) being prominent in the text. I would add a
short introductory text to each one of these to explain why they are
requirements. For example:
o Simplicity means the API is easy to adopt, less prone to developer
errors and easier to test. Simplicity is not the same as small, though
often a simple API is also small. A simple API should not depend on too
much prior knowledge/experience in order to be immediately useful to a
typical developer. Constructs in a simple API should require few
reserved names, and few parameters. Unless for obvious convenience, a
simple API will have only one way to exercise each significant function
(i.e. feature orthogonality).
* I'm not so sure that API handlers are necessarily evil. (As
I'm probably not going to be on the call, perhaps this can be expanded
upon via email?)
* There is probably a good argument for expanding on the Async
vs Sync part of the doc, possibly to offer some suggestions as to when
each of the approaches is appropriate. The draft text suggests that in
every situation, one approach will be favourable to the other, but I
wonder if there are cases where both could be useful and it may be
better for the developer (who is closer to the specific problem domain)
to decide which approach to use. (Imagine the chaos if the network stack
designers had decided that sync/async was preferable to async/sync.)
* The mention of the callback to indicate success/failure
reminds me of my personal gripe that the issue of reporting abnormal
behaviour is constantly present but seldom addressed. It would be good
if all APIs were to report failure in the same way, as this would
provide for a much more consistent debugging environment.
* On the issue of versioning, many APIs can identify the
specification they implement by reporting the IRI (URL) of the
specification. For example, implementations of the DDR API (recently
published as a Proposed Rec) return a String (which implementers agree
should incorporate the URL of the specification, in the same way that
reported DDR Vocabularies also report their IRIs). Returning a number is
not as specific, unless some agency is made responsible for the number
increments.
http://www.w3.org/TR/2008/PR-DDR-Simple-API-20080917/#sec-Service-getImp
lementationVersion
* Regarding the use of associative arrays for extensibility,
this is something that helps with backwards compatibility (as the
additional data would be ignored by older systems). The use of
associative arrays does not itself prevent newer versions of an API from
coming into being, and it wouldn't be a problem to completely re-invent
an API so long as there was a reliable means of detecting which versions
you were using, and were able to use whatever versions you discovered.
As this isn't always the case, backwards compatibility is seen as
desirable. However, as many versions roll over and the years go by,
backwards compatibility can be a barrier to innovation. This is a tough
call.
OK, that's enough for now. Again, my apologies for not being able to
make the call today.
---Rotan.
From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Andrew Sledd
Sent: 25 September 2008 11:55
To: OpenAjax Alliance discussion list on Mobile Ajax
Subject: [OpenAjaxMobile] Reminder: Conf call information
Hi all,
Just a reminder of the call in details and some links to relevant
discussion items.
Andy
Minutes of previous telcon
http://www.openajax.org/member/wiki/Mobile_Minutes_2008-09-04
See also Jon's Mobile Device APIs Stype Guide on the wiki (link inline
below).
Call Time: 9amPT, noonET, 5pm London, 6pm Paris
Passcode: 460566
Conference Access:
Toll free: 1-888-619-1583
Toll: 1-719-457-1414
International toll free - Argentina: 0800 666 3149
International toll free - Australia: 1 800 105 680
International toll free - Austria: 0 800 291 941
International toll free - Belgium: 0 800 75 240
International toll free - Chile: 123 0020 9725
International toll free - China, Northern Region: 10 800 714 1201
International toll free - China, Southern Region: 10 800 140 1180
International toll free - Colombia: 01 800 518 0789
International toll free - Costa Rica: 0800 015 0616
International toll free - Czech Republic: 800 700 294
International toll free - Denmark: 80 886 215
International toll free - Dominican Republic: 1 888 751 4488
International toll free - Ecuador: 1 800 020 321
International toll free - France: 0 800 90 0161
International toll free - Germany: 0 800 181 9019
International toll free - Greece: 00 800 161 2205
5955
International toll free - Hong Kong: 800 901 110
International toll free - Hungary: 06 800 162 50
International toll free - India: 000 800 1006 980
International toll free - Indonesia: 001 803 017 5955
International toll free - Ireland: 1 800 760 547
International toll free - Israel: 1 809 246 041
International toll free - Italy: 800 873 739
International toll free - Japan: 00531 16 0844
International toll free - Lithuania: 8 800 3 05 25
International toll free - Luxembourg: 800 2 7665
International toll free - Malaysia: 1 800 813 714
International toll free - Mexico: 001 800 514 5955
International toll free - Monaco: 800 93 416
International toll free - Netherlands: 0 800 023 5303
International toll free - New Zealand: 0 800 451 015
International toll free - Norway: 800 196 65
International toll free - Panama: 00 800 226 5955
International toll free - Poland: 00 800 111 49 58
International toll free - Portugal: 800 819 728
International toll free - Russia: 810 800 2704 1012
International toll free - Singapore: 800 101 2002
International toll free - Slovenia: 0 800 80203
International toll free - South Africa: 0 800 980 988
International toll free - South Korea: 003 0813 1963
International toll free - Spain: 900 947 604
International toll free - Sweden: 02 079 7556
International toll free - Switzerland: 0 800 564 397
International toll free - Thailand: 001 800 156 205
5955
International toll free - Trinidad-Tobago: 1 800 205 5955
International toll free - UK: 0 808 101 1146
International toll free - Uruguay: 0004 019 0188
International toll free - Venezuela: 0 800 100 8300
________________________________
From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Jon Ferraiolo
Sent: den 22 september 2008 17:47
To: mobile at openajax.org
Subject: [OpenAjaxMobile] Mobile Device APIs Style Guide
In preparation for Thursday's phone call, I wrote a first draft of a
style guide with a set of guidelines for how JavaScript APIs to mobile
device services should look.
* http://www.openajax.org/member/wiki/Mobile_Device_APIs_Style_Guide
I am expecting lively discussion on Thursday. :-)
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080925/e12808c9/attachment-0001.html
More information about the mobile
mailing list