Mobile Minutes 2008-04-03
From MemberWiki
URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-04-03
Contents |
Attendees
- David Boloker, IBM (co-chair)
- Rick Saletta, Wavemaker
- Nikunj Mehta, Oracle
- Jon Ferraiolo, IBM
- Paddy Byers, Aplix
- Kai Hendry, Aplix
- Anselm Garbe, Aplix
- Louenas Hamdi, SAP
- Ajit Jaokar, Futuretext
- Elin Röös,Ikivo
Minutes
White paper
http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax
Introduction
Jon: Nikunj, how about introducing the introduction changes you propose
Nikunj: I propose to beef up the introduction. State the goals clearly. State the audience clearly. State the intent clearly. State what the following sections will say. I have proposed new text.
Jon: I skimmed it and it looks good. I certainly like what you are trying to do. I request a day to review more carefully, but everything looks good.
Deadline for requesting changes
Jon: How about establishing a deadline for speaking up or forever holding your peace? How about end of day Friday this week?
Paddy/Erin: Fine
RESOLUTION: Everyone has until end of day Friday to make final proposals to white paper, at which point Rick Salette will do the final, final draft
Characterizing Mobile Ajax Support Today
Nikunj: Descriptions of Ajax characteristics isn't sufficient. We say that Ajax can be used in combination in multiple ways, but white paper has constant friction between talking about existing web site or optimized mobile web sites. Should say that existing web sites work with mobile ajax as we define it but optimizations will result in a better experience. Might be implicit but better to clarify this.
Jon: Not sure what you Ajax characteristics.
Nikunj: What Ajax is and its current status. Is there something that talks about this?
Jon: I don't think we have anything like that for desktop. Desktop browsers supported a set of features, and then the Ajax libraries found a way to do magic with existing desktop browsers.
Nikunj: WP1 had some text. WOuld be good to reference to that white paper and say what exists on mobile. Also, hard to find where mobile ajax is today.
Jon: Kai pointed out before others joined that we don't talk about the state of mobile ajax today sufficiently. I can take a crack at referencing Ajax characteristics from other white papers and summarize the current state of affairs. 1 or 2 paragraphs. Any objections?
Nikunj: Ok with me.
ACTION Jon to add 1 or 2 paragraphs about characterizing Ajax and current state
Mobile Ajax in Practice
Nikunj: I propose "Mobile Ajax in Action". That's what I see in other white papers. Better, shows power of the technology.
Jon: Fine with me.
ACTION Jon to change Practice to Action
Opportunities and Challenges
Nikunj: I propose promoting Mobile Opportunity to next higher level, remove short summary section before it, and remove Differences in UI section after it
Jon: That's what I was proposing, also
ACTION Change WP to reflect this suggestion
Design for efficient download and launch
Nikunj: Not good to have overlap between this section and network section. I have proposed how to merge into the network section, then remove download and launch section.
Jon: I agree there is overlap. Your proposals look good to me.
The graphic showing the performance table
Louenas: Don't know where to put this. I have heard lots of misconceptions about Mobile Ajax. People say it uses lots of bandwidth, but it does not. Depends on the app. We should try to remove the misconceptions.
Nikunj: Would be useful in the section Design for Network
Louenas: Maybe this graphic isn't correct for the white paper, but a picture helps out. Might be main takeaway.
Louenas: A study has found that network data has much more impact on battery than CPU processing that data
Jon: Where to put it? How about a new section, Performance Considerations, just before the tips section?
Louenas: Yes, maybe. I think it's a good idea
ACTION Jon: move table to new Performance Considerations section
Finishing the white paper
Rick: Just one more pass is all I can do
Jon: Therefore, I propose a Friday deadline, the Rick finishes it. Any objections?
(no objections)
Nikunj: I have added one new section that isn't colored blus, the network section. Just wanted to alert people.
Mobile Device APIs
Jon: Let's review David Pollington's email:
Objectives
Excerpt from David's email:
In addition to the 2 options already identified (device APIs specified, open source code), a third option (which is not mutually exclusive) is to provide a layered API model whereby the full set of device APIs may be provided by the underlying platform but the developer has the freedom of developing his own set of 'working' APIs through JavaScript wrappers. Such an approach has a number of benefits including a) enabling the developer to decide whether they want 10 methods for originating a call or just 1, b) enabling the community to provide a very simple set of APIs to enable Developers to get started (the iPhone originally only provided a single API method for originating a call to keep things simple). This point also relates to the notion of providing a modular architecture (developer deciding to use the location API without bundling in the others) but also enables a mashup approach to APIs whereby a developer could create a single API for accessing an address from the address book and fetching a map (e.g., 'get map for this contact' method). Getting the right balance between consistency/interoperability and flexibility will be the key hence the suggestion for taking a multi-tiered approach to API definition and usage.
Jon: I'm confused by what he means by "developer". There is the system developer working on the device or browser. There is the Ajax toolkit developer working on an Ajax library. And there is the app developer who is using the Ajax toolkit.
Nikunj: I guess that "developer" means JavaScript developer, such as the jQuery developers. But I don't understand fully.
Paddy: Anyone can write JS APIs on top of device APIs. People can use whatever APIs they like, such as an Ajax library, maybe OpenAjax Hub. But this is all out of scope of our discussion. It's just regular JavaScript development. How does that relate to us? First, maybe for security considerations. Perhaps we can allow applications to access high-level APIs but not lower-level ones. Could turn this into an objective. Second, the way a lot of frameworks work is that you don't always load the library directly, but instead you invoke a loader which then loads the library. A question we can ask is to request that device APIs can be loaded in some way. There has been some discussion at OpenAjax in this area. Call one API which then loads what is needed.
Jon: Such an approach aligns with the shim layer idea with providers. You say which provider you need and then its JavaScript gets loaded.
Paddy: We could define a portable APIs for that similar to Google's loader. Could have an open source implementation. When we define our scope, we might go beyond APIs but also the infrastructure that we need, including loading
Jon: Brilliant. I like it. But at this point, I don't think we can go any further than what you just said. We can conclude "we think we might need a loader" but we won't know for sure until we roll up our sleeves and start coding things.
Paddy: Sure.
Jon: I'll send an email to David asking for clarifications
ACTION Jon to ask DavidP for clarifications
Requirements
- Support for multiple Application deployment models 1. conventional websites; MAY? 2. locally installable widgets; SHOULD 3. pre-installed widgets. MUST The caveat here is the phrase 'subject to security policy'; if an adequate security mechanism can be defined and deployed then the answer could be Should or Must to all 3... - Support for multi-origin models Agree that a developer should be able to combine different modules to create a new Web app; the question is whether these are then bound up and signed as a package or whether the Web app is effectively assembled dynamically. We need to make this clear in the requirement (whichever way we choose to state the degree of compliancy required). - Support for extensibility Absolutely agree that developers should be able to define their own APIs and this could be effectively managed through a multi-tiered API model. In terms of API request, I guess it makes sense that the app has to pre-announce the APIs it intends to use to prevent the situation where the app loads and some of the functionality is denied by the underlying platform giving an inconsistent user experience. Enabling an app to determine underlying API support is probably a Must rather than a Should to allow apps to react accordingly and minimise impact on user experience.
Jon: David has comments about application deployment model. I agree with his comments.
Paddy: Yes, we do, too.
Jon: I will try to merge his comments into the text unless someone objects.
ACTION Jon to merge DavidP's comments about application deployment model into Requirements doc
Jon: Now to multi-origin model. Regarding his question, there are separate use cases for both.
Nikunj: Not clear what is meant. Different data sources or different markup or different script.
Paddy: I think we intend to support all of the above.
Nikunj: There may be different security concerns
Jon: This is going to come up again and again. Complex subject. I'll take the action to attempt to make the text clearer.
ACTION Jon to attempt to make multi-origin model clearer
Nikunj: Will benefit form other OpenAjax work in related areas? Just reference this? Nothing here that is unique to mobile.
Paddy: Security is the big issue. We have to think about when the system decides to grant access to an API, based on a particular identity. Question is whether the system can make a good decision if multiple different places are involved. The answer might be yes.
Jon: We are having discussions at the same time in the Runtime TF effort. It is a complex area. We have at least 5 different proposals for the desktop to minimize the problem of cross-site scripting.
Nikunj: One thing is that we need to make sure that the objectives capture this.
Extensibility
Jon: I would say the ability to query whether an API exists is a MUST
Nikunj: Not clear whether David is talking about extensibility of JavaScript or native code. Yes, JavaScript needs to be able to test to see what is available. Is that what we mean here?
Jon: I'm not sure who wrote the original extensibility text, Paddy, me or someone else, but my thinking was that extensibility was focused on the system side, where the device manufacturer or browser could innovate with newer APIs or extensions to existing APIs and not be constrained by whatever we do
Nikunj: Need to make this clear
ACTION Jon clarify extensibility section
Next meeting
Jon: Let's resume next week with David's section "Specific APIs". Hopefully David will join the call next week.
