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

Wed Sep 3 10:19:40 PDT 2008

Hi Rotan,
Yes, of course, the Geolocation WG does not yet have an approved charter,
and even if the charter is approved as is, there are lots of potential
changes that might happen along the way. Therefore, I agree that from a
formal process perspective, the current geolocation spec technically is
just a proposal. However, given the people who are involved in developing
the spec (e.g., Google, the mapping leader, and Microsoft, also big in
mapping), the degree of public discussion so far, emerging partnership
between W3C and the mobile operator community (in the form of OMTP), and
the prevailing political winds (favorable winds towards HTML5-related
efforts), my prediction is that this particular spec has a really good
chance of remaining largely intact. Of course, others might read the tea
leaves differently. Also, as one of the people at OpenAjax Alliance, I like
the APIs that they have developed, so at least one person at OpenAjax will
be supportive.

I definitely encourage appropriate liaison activities between W3C and
OpenAjax Alliance (and OMTP), whether formal or informal. Right now there
are 3 industry groups that are active in the device APIs area, W3C, OMTP
and OpenAjax Alliance. We should do our best to all march in the same
direction, and as far as I can tell, we all have sincere intents towards
working together in an effective manner. Here is my current thinking about
how to divide the work up:

* W3C develops the API specs that defines some (or maybe all) of the actual
JavaScript device APIs,
* OMTP develops security specs that the W3C can reference. W3C stays out of
security specs. (Traditionally, a difficult area for the W3C)
* OMTP defines JavaScript APIs for technologies that W3C hasn't launched
yet but that the industry needs. They specs might be transitioned to W3C at
a future time.
* OpenAjax reviews all of the above work and provides feedback,
particularly on how well the above work aligns with the needs of Ajax
developers
* OpenAjax might define some JavaScript APIs for technologies that the
industry needs but OMTP and W3C haven't started yet
* OpenAjax might launch on open source JavaScript shim layer activity that
allows JavaScript access to legacy device APIs, but such an effort probably
requires the available of mobile browser plugins such as Aplix's WebVM for
such an effort to be viable.

Jon

mobile-bounces at openajax.org wrote on 09/03/2008 01:10:31 AM:

> One of those inevitable email responses…
>
> Once again I urge caution in referring to this as a W3C
> Specification. It is not. It is a proposal submitted to the W3C for
> consideration as the starting point of work on a geo-location API
> spec. Currently no official group has been given formal
> responsibility for this work. It might even be the case that this
> particular submission is discarded in favour of something better.
>
> Matt Womer is the W3C staff member responsible for steering the
> proposal to set up a group to deal with geo-location. He is also my
> rep for the group I chair, but he is currently on vacation so I have
> no up-to-date information to offer regarding any progress being made
> on geo-location.
>
> It is my understanding that if the geo-location group is set up then
> the proposed spec will be taken under advisement, along with all of
> the technical comments to date on the public mailing list that was
> set up for the purpose. Obviously it would be of benefit for the
> OpenAjax Alliance to add to these comments. Furthermore, assuming
> the group is set up, the OAA can have an ongoing liaison with the
> group through the public channels and possibly through overlapping
> membership (a common informal mechanism that can be efficient and
> fruitful). A formal liaison for this purpose is unnecessary (not
> least because we could do without the paperwork!).
>
> Regarding Jon’s analysis, this is very comprehensive indeed!
> Assuming we can come to a common position on the matters raised, we
> can make a submission to W3C, via the appropriate list, to ensure
> they are considered when the W3C group is eventually formed.
>
> I’d also like to open an informal channel to Matt as soon as
> possible, and when the group is formed then we can arrange a joint
> teleconference to discuss any issues that arise.
>
> Finally, regarding Jon’s comment on “feature URLs”, the current
> approach within W3C is to use URIs (or increasingly, IRIs) as unique
> identifiers. It is not necessarily the case that an individual URI
> can be dereferenced, either to something human-readable or machine-
> readable. However, some groups take the view that they should
> dereference to something human-readable where the processing model
> does not require the referenced resource to be fetched. If you are
> familiar with DTD or Schema URLs you’ll understand this issue,
> although fetching is generally not performed for “well known” URLs*
> in order to avoid bottlenecks.
>
> ---Rotan
>
> * Some people use URL and URI interchangeably, though this is not
> strictly correct.
>
> From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
> On Behalf Of Jon Ferraiolo
> Sent: 03 September 2008 00:21
> To: mobile at openajax.org
> Subject: [OpenAjaxMobile] Analysis of W3C's latest geolocation APIs
> and proposals for how to generalize
>
> This email contains an analysis of the W3C's latest geolocation spec
> and some thoughts about whether it would be good to pattern other
> device APIs to use the same approaches. The email also makes various
> proposals about several open issues. We could probably spend the
> entire hour on Thursday walking through this email (and the
> inevitable email reponses that will arise between now and then).
>
> These comments refer to the Aug. 15 draft of the Geolocation API
> spec found at:
>
> * http://dev.w3.org/geo/api/spec-source.html
>
> ---------------------------
> EXECUTIVE SUMMARY
> ---------------------------
>
> Here are the key APIs defined in the geolocation spec:
>
> * navigator.geolocation.lastPosition - an object holding most recent
> geolocation position
>
> * navigator.geolocation.getCurrentPosition(successCallback [,
> errorCallback [,options]])
> --- successCallback is the callback function
> --- errorCallback (optional) is the error callback function
> --- options (optional) can include extra parameters and provides for
> future extensibility
>
> * navigator.geolocation.watchPosition(successCallback [,
> errorCallback [,options]])
> --- see getCurrentPosition()
>
> * navigator.geolocation.clearWatch(watchId) - where watchId is the
> return value from watchPosition()
>
> The successCallback receives a Position object defined as follows:
>
> interface Position {
> readonly attribute double latitude;
> readonly attribute double longitude;
> readonly attribute double altitude;
> readonly attribute double accuracy;
> readonly attribute double altitudeAccuracy;
> readonly attribute double heading
> readonly attribute double velocity
> readonly attribute DOMTimeStamp timestamp;
> };
>
>
> ---------------------------
> JON'S EVALUATION
> ---------------------------
>
> The W3C geolocation APIs are generally fine as is. The things I like
> about this API:
>
> * Simple and straightforward
> * Good design for future extensibility due to the options object and
> the position object
> * I think it is good that they have both successCallback and
> errorCallback as the first two parameters. This emphasizes to the
> developer that he might want to pay close attention to error
> handling, such as being denied access to the API for security reasons.
> * I think it is good that it the API is placed onto navigator.
> geolocation (versus omtp.whatever or OpenAjax.device.whatever)
> * I think it is good to allow direct JS access to the most recent
> position, such as window.geolocation.lastPosition.latitude, but the
> W3C spec needs to warn developers that if they attempt to access
> that property and they don't have permission, the property's value
> will be "undefined".
>
> My concerns about this API:
>
> (1) Not really a concern per se, but there is nothing in the spec
> yet about security.OMTP's efforts will supplement the work done by the
W3C.
> (2) There needs to be additional query APIs for:
> --(a) Checking to see if geolocation APIs are available
> --(b) If so, what version of the APIs are available
> --(c) Whether this particular application has permission to access those
APIs
> (3) There is no support for Bondi's requirements about dynamically
> loading of an implementation of particular APIs
>
> Regarding (1), the W3C geolocation spec could say something general
> about how a USER AGENT SHOULD provide a secure computing environment
> that has careful implementation strategy to protect the user's
> privacy, and then references OMTP's security spec as a security
> framework that can be used. My thinking is that the W3C isn't a good
> place to write security specs. In other words, as a general
> approach, W3C defines the APIs and OMTP defines the security model.
> (Although OMTP should work on APIs that the W3C isn't moving fast
> enough on yet and then probably turn those APIs over to the W3C when
> the W3C is ready.)
>
> Regarding (2a), the application can just check to see if the
> navigator.geolocation object is present (i.e., not "undefined").
>
> Regarding (2b), the W3C simply needs to put a 'version' read-only
> property on the Geolocation interface.
>
> Regarding (2c), I suggest that OMTP define the APIs for checking on
> whether an application has permission to use the APIs. I would
> suggest something like:
>
> * navigator.apiPermissionsCheck(api_uri, successCallback [,
> errorCallback [,options]])
>
> where the 'api_uri' is a unique URI for a given API module. The
> 'options' parameter provides an extensible architecture for the
> application to pass in parameters. (One warning to the Bondi folks:
> the W3C has some specs with feature URLs already, such as http:
> //www.w3.org/TR/SVGMobile12/feature.html. My guess is that Rotan can
> educate us about other relevant work at the W3C.)
>
> Regarding (3), long-term, I believe browsers will implement device
> APIs natively, in which case dynamically attaching an implementation
> is the minority case. Therefore, I think it is fine that the primary
> geolocation APIs are simple and don't deal with the dynamic loading
> features. Instead, dynamic loading should be a separate set of JS
> APIs. The geolocation APIs would use the currently loaded implementation.
>
> ---------------------------
> GOOD MODEL FOR OTHER APIs?
> ---------------------------
>
> Are the W3C geolocation APIs a good model for other device APIs? I
> would say yes. Here is a sketch for how other device APIs might look
> following the pattern established by the geolocation APIs. (I used
> http://www.openajax.org/member/wiki/OpenAjax_Device_APIs_Modules to
> help build this analysis.)
>
> Note that the parameters to the APIs would align with what the W3C
> has done with geolocation: successCallback, errorCallback, and options.
>
> Phone call APIs:
> * navigator.phone.call() - calls a given number
> * navigator.phone.answer() - answers the current call
> * navigator.phone.hangup() - terminates the current call
> * navigator.phone.{inbox,outbox,missed,all} - list management APIs
> (e.g., delete, get details)
> * navigator.phone.{watchIncoming(),watchOutgoing(),watchMissed()}
>
> SMS and MMS:
> * navigator.{sms,mms}.send() - sends an SMS or MMS
> * navigator.{sms,mms}.{inbox,outbox,drafts} - list management APIs
> (e.g., delete, get details)
> * navigator.{sms,mms}.{watchIncoming(),watchOutgoing()}
>
> EMail:
> * navigator.email.send() - sends an email
> * navigator.email.{inbox,outbox,drafts,trash} - list management APIs
> (e.g., delete, get details)
> * navigator.email.{watchIncoming(),watchOutgoing()}
> (there will be a number of other email APIs, but I am only providinga
sketch)
>
> AddressBook:
> * navigator.contacts: list management APIs (e.g., add, delete, get
details)
>
> Calendar:
> * navigator.calendar.{inbox,outbox,drafts,trash} - list management
> APIs (e.g., add, delete, get details)
> * navigator.calendar.{addReminder()}
>
> Tasks:
> * navigator.tasks: list management APIs (e.g., add, delete, get details)
> * navigator.tasks.{addReminder()}
>
> Power:
> * navigator.power.{powerSource,chargeLevel,criticalBattery,charging,...}
> * navigator.power.watchCriticalBattery(),watchChargeCompleted(),
> watchPowerSourceChanged(),,...}
>
> Network:
> * navigator.network.{current,cellular,wifi,bluetooth}.
> {signalStrength,networkType,criticalBattery,roaming,,...}
> * navigator.network.watchOutOfCoverage(),,...}
>
> Time:
> (Not sure what exists already in the browser, but if we need to
> invent something, here goes)
> * navigator.clock.{date,time,timezone}
> * navigator.clock.watchTimeZoneChange(),,...}
>
> Media:
> * navigator.resources.{images,audio, video} - list management APIs
> (e.g., delete, get details)
> * (need other APIs for capture and annotate)
>
> File I/O:
> * W3C is working on APIs in this area
>
> Camera:
> navigator.camera.*
>
> Effectors:
> * navigator.effectors.mode
> * navigator.effectors.setMode()
> * navigator.effectors.watchModeChange()
>
> Accelerometer:
> * navigator.accelerometer.mode
> * navigator.accelerometer.setMode()
> * navigator.accelerometer.watchModeChange()
>
> Memory:
> * navigator.memory.watchOutOfMemory()
>
> Console:
> (Need to see what browser APIs exist already. Firefox/Firebug
> definitely has a console object)
> _______________________________________________
> mobile mailing list
> mobile at openajax.org
> http://openajax.org/mailman/listinfo/mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080903/b46c21ed/attachment-0001.html 