Mobile Minutes 2008-04-24
From MemberWiki
URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-04-24
Contents |
Attendees
- David Boloker, IBM (co-chair)
- Andrew Sledd, Ikivo (co-chair)
- David Pollington, Vodafone
- Guillermo Caudevilla, Vodafone
- Jon Ferraiolo, IBM
- Paddy Byers, Aplix
- Nikunj Mehta, Oracle
Summary of New Actions:
- ACTION: Jon to remove the questions from the last section on the Survey page.
- ACTION: Jon to put Access & Blue Tooth into the Requirements List.
- ACTION: Jon to create a To Do page on the wiki. This page will capture all Actions necessary for completion of the clean-up of phase 1, uc and requirements development.
- ACTION: All to work actions. Take an un-assigned actions and assign it to oneself by editing the wiki. In this way we can avoid duplicating each others efforts and cover the Survey review more quickly.
Minutes - scribe Andrew
Scribe?
Andrew: Thanks to Jon for his exemplary work in minute taking. We agreed last time to rotate the minutes taking duty. Is there a volunteer for today's call?
Paddy: I might have to cut out but am willing to do it another time.
No takers.
Andrew: Then I will take notes today.
Security Concept Proposal by Paddy
Paddy : I think we can and should continue the security discussion via email. But we should involve the Security TF.
Jon: Yes, I sent an email to the chair of the Security TF and am awaiting response. I believe we have gotten far on the framework proposal and involving others from the that group will be good.
Mobile Device API Requirements
Application Deployment
Vodafone input on Deployment UCs
http://openajax.org/pipermail/mobile/2008q2/000218.html
David P: In our development of the UCs we were a bit unsure as to what Native Application terminology included, so we re-named the deployment method Site Specific Browser Application and this is our preferred naming, at least for the use case we present.
Guillermo presents UCs and describes the combination of Device API to local device information with web access to information:
Guillermo: For Native Application we think the term is confusing and that there is a better know term which expresses what we mean here. That term was introduced with Prism and used in Bubbles. The term is Site Specific Browser Application.
David P: a general example is that the Site Specific Browser Application (SSBA) is presented to the user and initiated thru normal means, say by clicking an icon. It uses the onboard WebRuntime to present the information in the application. The UI is optimized for the application purposes, showing only those controls which are necessary for the specific application.
Paddy: Yes, but this deployment model is doing more. Firstly, from metadata you can retrieve application specific detail. Secondly, the application is sandboxed to a degree and can add constraints like no cross side scripting or cookie capturing
Nikunj: Yes, we need to think about this as two distinct things the isolation level of the applications and the coarseness of the UI. In an SSBA isolation level is much greater than other deployment methods.
Paddy: It is important to separate deployment model from implementation architecture. SSBA implementation has impact on the security model but such a security model need not be restricted to this deployment model. For example a widget could offer the same isolation level.
Terminology discussion. AGREE to change the term to Site Specific Browser Application. Device API Requirements
Andrew: We've been reviewing existing API's as a means of determining a good scope for the UCs and Requirements. We've collected considerable information on the Survey page http://www.openajax.org/member/wiki/Mobile_Device_APIs_Survey . In line with this there was discussion last week and via email about the MSA (Java JSR-248 and 249). Nikunj made a proposal from that review which focused the scope to a few required features (http://openajax.org/pipermail/mobile/2008q2/000206.html) Multimedia, Location, Bluetooth, File and PIM, Messaging. The Device API Survey page has something similar but different in the very last section at the bottom; Location, Some parts of security, File & PM,
Content Handler, SIP.
Should we reconcile these?
Jon: One thing we need to do is to remove these questions from the Survey page and move relevant info to the Requirements page.
Jon: Regarding Content Handling - I don't think that is necessary as the Browser handles that. The Java API is basically a mime type mapping. Agreement to remove the Content Handling for this purpose.
Jon: SIP -
Nikunj: There are several important protocols currently in use. SIP is not currently used. For the time being network protocols should be considered beyond the scope of this group. We will use what's there in the browsers of today... primarily HTTP
Jon: going forward we may expand.
General agreement
ACTION: Jon to remove the questions from the last section on the Survey page.
Nikunj: The MSAs have been reviewed for finding requirements appropriate for us. We need to make a more thorough review of the information on the Survey page.
Andrew: What about an api for accelerometer?
Jon: What does that enable?
Nikunj: That provides, for example, the attitude of the device, the tilt of the device.
Jon: So you could automatically sense the change from portrait to landscape?
Nikunj: Yes.
Jon: We should capture this.
Andrew: Blue Tooth?`
Nikunj: is it a network protocol which should be treated as we discussed earlier or a feature?
Paddy: as part Java it provides a simple API call for accessing and transferring data. It's on the level of a serial port access to beam contacts to others, printer access, or simple file transfer.
Jon: this sounds like it could be complex, and maybe just now its not a high priority, but we should put it in the list and prioritize it later.
ACTION: Jon to put Access & Blue Tooth into the Requirements List.
Guillermo: In reviewing UC and requirements there are aspects of content management, application launching, background and foreground events and capability discovery which we need to capture.
Andrew: Yes and for many Java devices the Content Handler API helps enable the launching of other applications. We may choose to do this in another way however. Your suggestions are new and good things we need to get into the requirements list.
Andrew: At each face to face meeting I've attended, two topics have come up around which there seemed to be much consensus but which I'm not user have been addressed here. Specifically persistence, or offline use, and cross context scripting e.g. Google gears worker pools. We may have covered persistence but worker pools?
Jon: is it appropriate to add worker pools? This is not part of current web and not part of HTML 5. It is being distributed solely by Google and is not really part of the open web.
Andrew: I have no position currently, just wanted us to review all inputs before we determine that we are finished with Phase 1 of UC and Reqs definitions.
official time reached.
Andrew: Does everyone have a few minutes extra to discuss our status of completion?
Andrew: So, have we met our goals for UC and Requirements? We are very close to the deadline of April 30.
Jon: I think we can say we've met our goals. We've certainly amassed a great deal of information and established a list of UC and Requirements. So let's recognize that achievement and then do some clean-up and the last of the due diligence. I propose the 8th of May as a date when clean-up should be completed. By that time we should have reviewed the Survey page and completed all Actions.
General Agreement
ACTION: Jon to create a To Do page on the wiki. This page will capture all Actions necessary for completion of the clean-up of phase 1, uc and requirements development.
ACTION: All to work actions. Take an un-assigned actions and assign it to oneself by editing the wiki. In this way we can avoid duplicating each others efforts and cover the Survey review more quickly.
Andrew: Lastly, there was some discussion via email about the security framework proposal made by Paddy. Is there something we should be doing to close that out?
Paddy: we'll this is a proposal to address the specific security consequences for the UC we've defined. It's more important at this stage to identify the UC, the requirements and the security consequences than it is to discuss this framework proposal for meeting them. I can work on this.
Andrew closes the meeting.
