Mobile Minutes 2008-04-17
From MemberWiki
URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-04-17
Contents |
Attendees
- Nikunj Mehta, Oracle
- Jon Ferraiolo, IBM
- Andrew Sledd, Ikivo (co-chair)
- Guillermo Caudevilla, Vodafone
- David Pollington, Vodafone
- Guillermo Caudevilla, Vodafone
Regrets:
- Paddy Byers, Aplix
Minutes
White paper
Andrew: Jon, do you have an update on the white paper?
Jon: I submitted it to the Marketing WG. No email feedback so far, but I got private feedback from ILOG that they will assume a professional writer to do an editorial pass sometime this week. That's the main value-add we need from the Mktg WG. If ILOG doesn't come through, I have others who have done similar things in the past. There will be a Mktg WG phone call in the next couple of weeks where we will discuss the white paper. After that, email +1 voting within Mktg WG and then email +1 voting by Steering Committee. Then I am proposing that the Mktg WG find volunteers to condense into about 2000 words by June for the Sept. publication of AJAXWorld.
Minute takers
Andrew: Can people volunteer to take minutes?
Nikunj: Is it possible to have audio recordings of the minutes
Jon: I'll check into that.
Andrew: For next week.
Vodafone use cases document
(sent by Guillermo via email before the meeting)
Nikunj: We should reconcile and merge into the requirements document first before discussing
(Jon agrees)
(Jon realizes that the document is a set of use cases with requirements necessary to fulfill the use cases)
Jon: Let's add the Vodafone use cases to the end of our use cases wiki page
Andrew: Add add requirements from those use cases that aren't listed on requirements page
Jon: Yes
Guillermo: This was an exercise to describe some use cases to help us identify and prioritize APIs that are interesting and see which APIs appear most frequently. We hope others in the alliance will do the same. And maybe then discard or postpone some APIs until a second phase. It becomes clear that a popular API is location.
Andrew: We have found that lots of applications are embedded and use location, camera, and mapping. Your travel blog for example.
(DavidP joins)
(Jon summarizes previous discussion)
Andrew: And one we have a list of requirements, we prioritize them as a second step.
DavidP: Yes, this was an exercise to see what APIs are most important. Yes, camera is important. But we are looking at a more detailed level to see how much complexity is needed for each API.
Jon: Going up to a higher level, what I have been thinking is that in April we aren't going to get anywhere near finishing up the use cases and requirements, but we are trying to get far enough that we have a view of the landscape such that we can make decisions in May about ways to go forward.
Nikunj: I suggest keeping Guillermo's use cases structure
Jon: Yes, I'll merge them in and I'll preserve his structure.
Andrew: Also, add header saying where the use cases came from and that we are moving some of the requirements onto the requirements page.
Nikunj: Need to link use cases with requirements.
Andrew: Yes, but maybe later. Do people agree with what Jon has proposed? Let's get down our thoughts in APril and then make a proposed way forward in May. As part of that future work, maybe we clean up the wiki and add cross-links.
Nikunj: My concern. I would like to make sure everything is in the requirements.
Andrew: Will you take an action?
Nikunj: Yes, I'll do that.
Andrew: Ok with you, Guillermo?
Guillermo: Yes
ACTION Nikunj to study the VF use cases and make sure all of them are captured within the requirements page
Jon: We also need ultimately to do careful study of Java MSA and OMA's lists of APIs to make sure we have a complete list of candidate APIs. But right now we only need to skim things and make sure we aren't missing a major category.
Andrew: Yes, good idea. But maybe going beyond skimming we would balance against time to market goals.
Nikunj: I have already done a first pass on the OMA document and added those to our requirements page.
Jon: Great!
Andrew: (Talking to VF) Anything in particular from the use cases document that you want to highlight?
DavidP: Nothing in particular. Just some input that we have provided.
Andrew: I see that you tactfully avoided security
(DP laughs)
Andrew: Security should impact usage, but not the APIs themselves
Nikunj: Security is a runtime issue, APIs are design time. Should be orthogonal. Have to keep them separate.
Andrew: Exactly.
Deployment models
(from requirements page)
Andrew: Let's just to the requirements page and go to the deployment model section
Andrew: Nikunj could you go through the 4 deployment models?
Nikunj: Based on the kinds of apps that people would want to build. Draws from desktop deployment but adds some mobile. First, browser. Is that a top goal of OpenAjax? Is so, it should be a MUST. Do we need additional text to mention this as a top goal?
Jon: Agree. No need for additional text. Fine as is.
Nikunj: Second, widgets. Variations of pre-installed and user-installed. I said SHOULD to promote the model for widgets, but we should do this only if widgets are going to be key to developers.
Jon (and someone else): Lots of emphasis on mobile widgets, more than on the desktop
Nikunj: If so, it should be a preferred model.
Jon: I agree with SHOULD for widgets.
Nikunj: Third. Browser control in native application such as help system. Or news feed about a particular company. I say MAY because we don't need to promote this because Ajax isn't the full model.
Jon: I agree with MAY.
Nikunj: 4th is site-specific browser. Instead of a general browser that can navigate to the full web, only used for a specific app scenario within one web page or a set of web pages. Also, there is some desktop integration usually. Depends on various things, such as packaging. Firefox has Prism. At the very least I wanted to highlight this emerging category.
Andrew: Dynamically deployed web content with a dedicated server with a particular deployment scenario. Correct?
Nikunj: Difference between 2 and 4: with 2, different widgets use the same process, with 4, each app has a different process. 4 also acts as a native application.
Andrew: I support 4
DavidP: There is always a gray area between web pages and deploying and executing locally. With browsers and then widgets and then Gears in between. Often about user perception and technology used, such as Ajax or Silverlight.
Andrew: It's complex. We will have a better idea as we work through use cases and requirements.
Nikunj: One more thing. #4 allows Ajax to be used as a replacement for what Oracle is doing now with Java.
Jon: How about changing the title for #4 to "hybrid browser application".
Nikunj: That's fine. Would need to explain.
Jon: Have the first sentence talk about site-specific
Nikunj: Fine.
Nikunj: Need use cases for this.
Andrew: Guillermo and David, which deployment models are you using in your use cases?
DavidP: We could easily create use cases for each deployment model. It boils down to which service you are trying to deliver and how much is dynamic.
ACTION to all to add use cases for each deployment model
Jon: Can we take these 4 deployment models and put onto the use cases page so they match?
Andrew: Yes
Nikunj: I'll do that
ACTION Nikunj to update use cases page with the 4 piece deployment model
Titles
Andrew: Nikunj has proposed changes to the section titles on the requirements page. I think his changes are fine.
Jon: Nikunj is right
Andrew: OK, let's accept his title changes
DavidP: Regarding "device service API requirements", programmers usually think only about device apis
Andrew: We have heard that device manufacturers consider device apis to be broader than this
Nikunj: I'll take a second pass and will clean up titles and the deployment model section
ACTION Nikunj to clean up titles and the deployment model section
