From MemberWiki

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