Mobile Minutes 2008-03-13
From MemberWiki
URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-03-13
Contents |
Attendees
- Andrew Sledd, Ikivo (co-chair)
- Rick Saletta, Wavemaker
- Nikunj Mehta, Oracle
- Jon Ferraiolo, IBM
- Paddy Byers, Aplix
- Ajit Jaokar, Futuretext
- Clayton Morlock, Tele Atlas
- Guillermo Caudevilla, Vodafone
Minutes
White paper
Andy: Last week we asked Rick to get the document into a final state
Rick: Wednesday I took a pass through everything and forwarded it to Jon. IMO looks pretty good. Maybe we can finish with a pass next week.
Jon/Andy: No phone call next week due to AJAXWorld and holidays in Europe. In 2 weeks.
Jon: I didn't understand the emails because there were some red-colored questions in there still.
Rick: What the red color means is that I haven't yet addressed that particular comment. All other comments are addressed.
Jon: OK. I'll post the updated documents either today or tomorrow.
Andy: What do we do about marketing the white paper?
Jon: Marketing WG will review and hopefully we will find someone to do an editorial pass. Then they will post on our web site alongside the other white papers.
Andy: What about AJAXWorld?
Jon: Yes, then we will probably submit the article to sys-con for both AJAXWorld online and print.
Jon: There are still a few things to do, but we have gotten past the hardest ones.
Rick: Some places need a little more content. Just a small effort from here.
Andy: Rick, thanks for all of your effort.
Device APIs use cases
http://www.openajax.org/member/wiki/Mobile_Device_APIs_Use_Cases
Andy: Last week we went through the use cases wiki page. I don't believe we finished our review. We did discuss whether to have 3 groups or 2 groups and decided on two groups, browser-based vs installable.
Jon/Andy: Now reflected on the use cases wiki page
Jon: Since last week, I added subsections on requirements that fall out and security. These are minor additions.
Paddy: 30 minutes ago I submitted suggestions on both use cases and requirements. I thought these topics would be worth discussing. There are 3 mechanisms listed, but the distinctions are a bit blurred. For example, on an iphone, you can locally install a bookmark which launches something that runs in the browser. Other categories are app construction model, single vs multiple origin, and then a set of use cases around authority. This is about who defines the policy, locally on device? User defined? Operated defined? These are all different aspects to use cases.
Jon: Some of the content seems to be oriented around how something is done, but with use cases it is common to focus on the what. But I need to think about which sections are what are which are how.
Paddy: Valid comment. Sometimes difficult to distinguish.
Jon: We have a separate wiki page for security. I think it is important to do our best to keep security independent of the other features. Can't keep entirely independent. But I fear that security discussions can become a rathole and make it impossible to progress on other fronts if every discussion launches that rathole.
Paddy: Yes.
Paddy: On the authority section, one of the goals was to have discussion about whether particular features are needed or not. As an operator, do you need to control which web sites can use device APIs?
Jon: Yes, that's a good area for discussion.
Nikunj: One thing last week, we were talking about the completeness of the use cases. Paddy shows a range of scenarios. Without this range, the uses cases are not useful.
Jon: I would say that some of the content in authority represents particular requirements that we need to prioritize. I have set up the requirements page as a bulleted list of items that we look at to decide how critical that item is.
Paddy: Generally agree, but things often begin earlier than what is listed in the current scenarios. Some of the scenarios begin with the provisioning.
Andy: The 3 sections we had from last week break up scenarios based on how they are provisioned. From these scenarios, the requirements and security features fall out.
Jon: What I'm thinking is that some of the items from Paddy's use cases would fall into a "Variations" section under the existing scenarios. This is a common approach with use cases. You describe what is trying to get accomplished, then list variations in the technical approaches that might be used.
Paddy: Sounds fine.
Mobile Device APIs Requirements
http://www.openajax.org/member/wiki/Mobile_Device_APIs_Requirements
Jon: I see Paddy's requirements more as mega requirements, and the existing requirements as micro requirements.
Paddy: Yes, my requirements are mainly meta requirements.
Jon: Very good contribution
Nikunj: Yes, largely orthogonal. Needs to address local caching requirements.
Jon: Like Gears?
Nikunj: Gears or something else like what Oracle is working on. Offline data storage.
Andy? Nikunj?: Need all 3 of storage, access and sync.
Paddy: I treid to set context. Do we need a scope? What do we mean by device APIs? Three things:
- Local services, for example make a phone call or access PIM
- Relocating info to the device, such as local storage
- UI-related things, eg. softkey support
Nikunj: Need to flesh out the persistent storage features more
Paddy: Yes, we need a proper set of detailed requirements
Jon: I can merge Paddy's use cases and requirements
Paddy: I can populate the security wiki page
Jon: I'm very happy with all of this progress in such a short amount of time!
Jon: Let's just go and update the wiki and send email when we are done.
Nikunj: Then I'll add my changes.
Andy: Guillermo, do you want to say something about Vodafone and MobileScript?
Guillermo: MobileScript is something that we have developed in R-and-D. In order to demonstrate and drive the innovation at other companies. Used spidermonkey and .... In betavine as open source. Our idea, not religious about MobileScript. Not attempting to create a standard or defacto standard. Just submitted as input.
Andy: Great.
Guillermo: We have videos from MWC. Some examples are simple. Get contact and go to Google Maps, how to get to contact's home address. Weather widget uses current location info. Widgets for call management and messaging management with different profiles for home and work.
Andy: Videos give a good idea of range of what we need to capture. Of course, need to delve deeper into the details. Makes me believe we are going in a good direction, but others please speak up if you disagree.
Jon: On the requirements page, I proposed a process where we assign a simple label of MUST, SHOULD or MAY to each line item. MUST means our effort isn't viable without that feature. SHOULD means we probably need it. MAY means it is optional. Supplemental comments are used to explain. We did this in the IDE WG and it went well. When we finished a line item, we put "Approved" in green so we know that that line item has already been finalized.
Andy: Anyone oppose or want to suggest an alternative?
Paddy: Sounds good to me.
Jon: I want to emphasize that we don't need to finish discussion of every line item by end of April. We are in the exploration phase. If we decide to charter a formal activity, then that formal activity can choose to finish up the detailed requirements.
Nikunj: Need to make sure that what we are doing is useful to the industry and that our efforts have credibility.
Ajit: Maybe open source? If so, then maybe an Apache license to promote usage.
Jon: Yes, we talked about an open source option both in Barcelona and in our phone calls here. If we do open source, it will be Apache v2.
Jon: But back to Nikunj's comment. I think it is an important point and we should attempt to capture at a high level what we are trying to accomplish. I am thinking of creating a 4th wiki page called Objectives.
Andy: Maybe the scope section could go there.
Ajit: Maybe should open up discussion with the public
Jon: Yes, please do. Our email lists and minutes are accessible to the public. The only constraint is that for IP reasons the public cannot add to the wiki or send emails. Only people who have signed the Members Agreement can do that. But we want this to be an industry-wide thing. Please evangelize.
