[OpenAjaxMobile] Minutes 2008-09-25 and updated style guide

Sat Sep 27 05:12:32 PDT 2008

At the bottom of this email are the minutes from our Thursday phone call.

During the phone call, we discussed the Mobile Device APIs Style Guide:

*http://www.openajax.org/member/wiki/Mobile_Device_APIs_Style_Guide

I have now updated the style guide to reflect the discussion on Thursday.
We decided to leave the document mostly intact because the community (both
OMTP and W3C) has already begun discussing its contents, and we wanted to
minimize confusion by having the document change too much in the middle of
debate of its merits. To see what changes I made, here is the Change Log
(which is now at the top of the document):

---------------------------------
Change log

2008-09-26

Various changes to reflect discussion at the 2008-09-25 phone call.
      Beefed up the introduction to attempt to be clear about what this
      document is trying to do and what it isn't trying to do. Emphasize
      that the document was created at the request of the OMTP to reflect
      the "Ajax/JavaScript perspective". Indicate that we recognize that
      there are other perspectives that OMTP and W3C need to take into
      account, also.
      In the section on Requesting and Checking Permissions, removed our
      previous recommendations for canUse() and apiPermissionsCheck() and
      instead this section now simply attempts to describe the requirement
      for browser-based applications to be able to request the use of
      device APIs
      Added some editorial comments to the Directness section to reflect
      discussion during the 2008-09-25 phone call
      Added a recommendation that OMTP define its APIs on its own global
      object (e.g., window.bondi) in order to prevent conflict from future
      overlapping specs from the W3C
      Add new section about error handling with sync APIs, where we
      identify some alternatives, but then say there isn't one preferred
      way.
---------------------------------

Below are the minutes from Thursday's phone call:

--------------------------------

Mobile Minutes 2008-09-25

URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-09-25

Attendees
      Paddy Byers, Aplix
      Andy Sledd, Ikivo
      Jon Ferraiolo, IBM
      Adam Peller, IBM (and Dojo)

Minutes

(reviewing
http://www.openajax.org/member/wiki/Mobile_Device_APIs_Style_Guide_

Andy: Rotan suggests IDL. I thought we talked about that last phone call.

Jon: (Looking at minutes) Yes. Last time Rotan suggested that we just focus
on JavaScript and not worry about other languages.

Andy: Right after you say that OpenAjax Alliance focuses only on JavaScript

Jon: The two audiences for the style guide are OMTP and W3C. We were asked
to do this style guide by OMTP folks, Nick Allott and David Pollington in
particular. OMTP is mainly interested in JavaScript, right?

Paddy: Yes, I believe that is so.

Jon: On the W3C side, times have change in the past 13 years. When DOM
started, Java applets were a much bigger thing and JavaScript was just for
small things in the browser. Now, people are trying to use JavaScript for
major development. ECMA4 was an attempt to make JavaScript into a major
language. More recently, there is a race to speed JavaScript performance,
with JITs and everything. It's now OK for real programmers to use
JavaScript. So even on the W3C side, JavaScript might have more importance
than previously.

Andy: OK, let's have others look at other languages.

Jon: I suggest that we include in the intro more explicit comments to
emphasize that we are focused only on JavaScript.

Paddy: A couple of personal reactions and a report on some recent chat at
the W3C. First issue is directness. At the W3C, there are a couple of
different opinions. One said that directness was good. Another said this
contradicts the current draft of the widgets spec. There, you have a config
doc which lists the API dependencies where each feature has an API. You
specify the API you want to use with a shortname and an URI, similar to XML
namespaces. This makes the API available to the widget but doesn't bind
into the JS environment. Then the widget does a getfeature and then gets
the root object of that API.

Paddy: This is part of a draft document that is still under discussion. The
advantage is that you don't have to manage conflicts over multiple APIs
wanting to be at the same location. Jon's proposal contradicts the latest
widgets proposal.

Andy: I assume the directness recommendation was intentional, but was the
contradiction with W3C Widgets intentional?

Jon: The directness recommendation was most definitely intentional. The
reason we did the style guide was because we were asked to express the
point of view of the Ajax/JavaScript developer community. There has been a
clear consensus among the Ajax toolkits that has emerged around making APIs
available in a direct manner. I mentioned an example of how Dojo went from
indirect APIs in dojo 0.4 for client-server communications to direct apis
in dojo 1.0.

Paddy: The webapps discussion list also talked about the risk of API
hijacking.

Adam: There is work at ECMA 3.1 to have the ability to seal off certain
objects.

Jon: The risk of hijacking a JavaScript object is across most of JavaScript
today. It wouldn't be a new thing for device APIs. JavaScript today is very
flexible.

Paddy/Adam: (comments about how different browsers offer different
abilities and constraints around changing the JavaScript environment, how
some browsers allow changing the prototypes for built-in objects such as
Array)

Adam: Next draft of ECMA will attempt to provide more consistency

Jon: The fundamental basis of web security is that a user goes to a web
site and then the web site controls the bits that come down to the user's
browser. Since the web site controls the content, the web site can prevent
hijacking.

Adam: Except for mashups, for which there are isolation approaches, such as
what OpenAjax is doing.

Jon: Yes. But I'm not buying the argument that requiring indirection before
getting access to APIs provides a tangible security advantage.

Adam: Also, ECMA might be coming in same timeframe.

Paddy: Takes a long time to get new features into browsers. Can't have a
dependency on EMCA.

Adam: Yes, can't assume that these new ECMA features will be available. But
we can say that our problems are the same as the rest of the Web.

Paddy: That's one topic. It would be good to continue to watch webapps and
BONDI discussions.

Paddy: We have just made changes to WebVM to match W3C Widgets.

(Jon/Paddy try to find the load/bind features in the W3C Widgets specs but
can't find them. Paddy will research and point out which specs have these
APIs.)

Jon: Adam, as a long-time developer of an Ajax toolkit, what do you think
about the directness issue?

Adam: Complex APIs tend to collapse from their own weight, with load and
register complexities. These approaches are foreign the JavaScript and Ajax
developers. You are going down the road towards something like CORBA.

Jon: Not that there is anything wrong with the more complex approaches.
It's just that we were asked to represent the perspective of the JavaScript
developer community and produce a style guide that aligns with their
collective point of view.

Adam/Jon: The Ajax community has gravitated to simple and direct APIs.

Adam: Granted, the Ajax community isn't dealing with host environments.

Jon: How about we emphasize in the preface that our recommendations reflect
the point of view of the Ajax community, which is just one point of view
among others. Also, emphasize that our recommendations reflect the
requirements from JavaScript developers, but there are other requirements
that we aren't taking into account.

Paddy: I think that's OK.

Paddy: getfeature avoids the need to manage namespaces. Allows two
different APIs for same feature without worrying about conflicts.

Andy: Should we say that we realize that our proposal not allow multiple
APIs for same feature?

Paddy: Advice to BONDI: put APIs onto a bondi. object but recognize that
those APIs might move to a different place in the future

Jon: For example, move to navigator object when W3C takes over a spec?

Paddy: Yes

Jon: Other things?

Paddy: People have objected to the security check APIs. People say you
shouldn't allow programmatic access to check security. Some say it is
unnecessary and others say this is a vulnerability since a web page can
check to see if access is possible without user knowing that the web page
is looking for attack opportunities.

Andy: Would this really happen in practice?

Paddy: Instead of asking whether you can use an API, instead you would try
to use the API and then a security exception would be raised. The idea is
that when a widget gets installed, it says what features it needs, and
either succeeds with installation or fails. If success, then the widget can
use the features.

Jon: From a security perspective, what's the difference between calling a
function to get a return code to see if you have permission or calling a
function and seeing if an exception is raised?

Paddy: Not much. But the checking function might invoke a prompt to ask the
user to allow access.

Adam: The common pattern in the JavaScript world is to check for existence

Jon: Two separate workflows. With widgets, there is an installer when
permissions can be checked. But what about a mapping browser application
where the app wants to show the user's current location? There is no
installer involved. You just go to the web page. The web page needs to know
whether it can use the geolocation APIs or not.

Paddy: BONDI hasn't looked at this workflow yet. In BONDI, the binding
action is when the exception might be called, and the exception has a
return code. But when you call the action, there is no way to introspect.
Not sure if introspection would provide greater vulnerability. Not much
detail in W3C discussion about introspection APIs other than "I don't like"

Jon: It's OK with me to drop the introspection feature. I thought there was
a requirement for them based on our work last spring and the BONDI
requirements. OK to leave it off and wait until someone says they need it.

Andy: But isn't there a workflow that will need this?

Paddy: It is likely that if you had a web site that needs the API and you
go to it for the first time, then the platform would prompt you if it's OK.
In some cases, maybe Vodafone has a deal with Google, and permissions for
Google are put into the phone and the Web site just works. BONDI doesn't
have introspection APIs. These are interesting suggestions, but maybe
allowing discovery without anyone knowing about it isn't good

Andy: (question about user experience)

Paddy: We don't know about the best user experience yet.

Jon: If I were on the other side and I saw this feature and heard Paddy's
explanations, I'd be worried too.

Andy: Are we unanimous for removal?

Jon: I suggest that we have a page that talks about the workflow
requirement, but list the potential problems with an introspection approach

(everyone ok with that)

Paddy: Another item. sync vs async. With async, you can't raise an error,
so errors must come through callbacks. But with sync, you can either return
a value, or throw an error, or invoke a callback. What is the
recommendation?

Jon/Adam: No standard answer. The Ajax community hasn't gravitated to any
one approach. It's more of a matter of personal taste and opinion.

Paddy: Can we include a comment about this?

Jon: Yes

Jon: I'll make incremental changes to reflect our discussion. That way,
people who have already looked the first version will see something that is
familiar to them when they see the updated version.

end of meeting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080927/355e000a/attachment.html 