Mobile Minutes 2009-02-12
From MemberWiki
URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2009-02-12
Attendees
- Jon Ferraiolo, IBM
- Mohammed Dadas, Orange France Telecom
- Dan Appelquist, Vodafone
- Adam Peller, IBM
- Guillermo Caudevilla, Vodafone
- Andrew Sledd, Ikivo
- Paddy Byers, Aplix
- David Pollington, Vodafone
Original Agenda
- Summary: Discuss latest BONDI specs and work towards official OpenAjax feedback on those specs.
Minutes
Jon: I propose that we do an overview and introduction today, then spend two weeks on email and wiki, and then assemble in two weeks to consolidate feedback into a report
Andy: Let's ask what the BONDI people want out of OpenAjax. What should we be looking for? API feedback? Formatting feedback?
Dan: We are looking for feedback on implementation of the APIs. Are the APIs friendly enough to Web developers? Not just the Mobile TF opinion, but rest of alliance.
Jon: Let's use the wiki to collect feedback. Wiki page with introduction to BONDI and links to the BONDI documents. Then send email to OpenAjax participants asking for feedback. We used such a wiki-based approach for the browser wishlist. Worked well, despite the free-for-all approach. In two weeks, consolidate the feedback.
Andrew: That approach has worked well in the past. Open to the whole alliance.
Jon: I'll send email to the public (non participant) list also. They can't edit the wiki and maybe no one will respond, but doesn't hurt to ask. Their feedback would have to come via email.
Jon: I would propose 3 (no wait, 4, no wait, 5, no wait, 6) wiki pages:
- Intro to BONDI, say we are looking for feedback, here is how to provide feedback
- JavaScript API approach - good or bad
- Security approach - good or bad
- Spec errors
- (this issue came later in the phone call) How OpenAjax can help evangelize BONDI
- (this issue came later in the phone call) Features for BONDI v2
Jon: Security looks like what we asked for. In fact, that's true across nearly everything I see
Dan: We aim to please
Paddy: We are looking for detailed review of the APIs. Unfortunately, not much public review yet. On security stuff, two angles: (1) are there any security holes, (2) you could argue we have just moved the problem. Policy moved to someone else. Practicality is an issue.
Jon: Yes, I noticed that.
Dan: Spec errors would be very useful.
Jon: What's the finalization timeframe for BONDI 1.0?
Paddy: Not defined. Instead, we have defined the gate.
- Need a certain minimum time for consultation with reviewers
- Need to create reference implementation
- Need to create test suite
- Need to verify RI passes TS
Test suite schedule isn't defined yet
Jon: Optimistic guesstimate?
Paddy: 8 weeks is optimistic
Jon: My instant review comment is that JS APIs are fine. The security features are generally what we requested. The OpenAjax style guide recommended against the loading of particular features, but we also had caveats at the top that we have a particular point of view and that it very well may make sense due to other constraints or requirements to choose different approaches. In the case of the loader, I think you made the right choice and tradeoffs. Big thing is getting the rest of the industry to adopt.
Paddy: What can OpenAjax do?
Dan: Evangelism certainly. Maybe an alternate implementation.
Jon: Let's have a 5th wiki page for evangelism
Dan: Starting to hear lots of comments about HTML5 immersive widgets. Kai Hendry wrote a good post on how BONDI is not incompatible with HTML5. Needless controversy. One area where OpenAjax can take a stand.
Jon: Let me think about what we can do about that.
Jon: One thing to consider is the OpenAjax browser wishlist update that we will be doing this spring. Definitely want to put BONDI on the list. Would be great if it got lots of votes, but without good education, it might not. Need to think about that.
Guillermo: Late March is our next F2F. One area to discuss is new APIs for a second release. Would be great to have OpenAjax input on that.
Jon: Another wiki page. My feeling is that there is a lot there with 1.0. Focus on getting it adopted.
Guillermo: Also, how to get more adoption? Put into WebKit? Mozilla? Multiple operating systems? Different devices? That will be on the agenda. Great to have feedback.
Jon: What's happening with Mozilla?
Paddy: Some discussions of an alternative reference implementation. But no embedding API like what you have in WebKit.
Jon: But Mozilla has an extension manager.
Paddy: Yes. That would allow BONDI APIs to be added to Mozilla. But to use Gecko to render widgets, harder.
Jon: XULRunner?
Paddy: I don't know the details. But they have been talking about adding an embedding API, but not done yet.
Jon: Other requests?
Paddy: Wiki pages are a good idea
Jon: Who on the call doesn't understand BONDI?
Andy: Somewhat
Adam: Not familiar with it
(Jon gives summary, not minuted. Something similar will appear on the wiki soon.)
Jon: Most of BONDI is outside of UI, but there is a feature for dealing with menus. That's for the two buttons just above the keypad on old-style phones, right? What happens with a touch device like the iPhone?
Paddy: I'm not close to that API, but it is supposed to provide an abstract API which a device can deliver however it wants to. On Windows Mobile, adds a menu button. Modelled after Nokia's similar APIs.
Jon: Networking APIs - For XMLHttpRequest, you have to go through BONDI?
Paddy: No. The intention is that when JS attempts to go through XHR, the implementation runs the request through BONDI security first.
Jon: Same thing for all of the HTTP GETs, such as SCRIPT SRC=?
Paddy: Yes
Jon: On the filesystem APIs, what about "virtual roots"?
Paddy: There will be designated areas on the local file system that you can write to. Not the whole disk. Each area has a well-known rootname. Often, each widget has its own private storage with a well-known name. Some shared areas such as gallery, also with a well-known name. Modelled after similar Java APIs.
Jon: OK, thanks. Next, digsigs. I understand what's going on with widgets, but I have questions about digsigs on web pages. What's going on here?
Paddy: For a normal web site, key attribute is the URI of the web site. But if HTTPS, you also have attributes about the certificate. Not signing the content, but info about the SSL connection. Allows decisions based on attributes of SSL certificate
Jon: OK, thanks.
Jon: Any relationship to Netscape signatures?
Paddy: No, we looked at that. Mozilla supports Zip, actually Jar, and the jar: protocol, and allows browsers to point to assets within the jar. In theory, BONDI could use such a feature in the future. Not widely supported yet. But for now, HTTPS addresses some key requirements. If I trust my bank over HTTPS, I probably can trust it to access certain device APIs.
Jon: Policy grammar. Looks like it modeled after XACML, but not transcodable into it. That's what the spec says.
Paddy: Yes. We tried to do a subset of simplified XACML that could be transcoded into XACML, but it became too contrived. Decided to give up to make it cleaner and simpler. Eg. we needed to allow attributes to be 'undefined' in JS. Also, the combining rules in XACML not quite right. However, if XACML adds a small number of small extensions, then you could transcode.
Jon: I buy it. My intuition is that you made the right tradeoff.
Paddy: Tried to follow Rotan's guidelines posted at OpenAjax about how to design a good XML grammar. Natural as how an author would say it.
Jon: Next question: not sure I fully understand the PRESENTATION element with options background and hidden.
Dan: To some extent, that's up the implementation. Hidden means it is performing a background task.
Jon: OK. One worry is whether this feature is sufficiently defined. I'll check.
Jon: Same time in 2 weeks?
(yes)
