Mobile Minutes 2008-04-10
From MemberWiki
URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-04-10
Contents |
Attendees
- Nikunj Mehta, Oracle
- Jon Ferraiolo, IBM
- Paddy Byers, Aplix
- Andrew Sledd, Ikivo (co-chair)
- Guillermo Caudevilla, Vodafone
- David Pollington, Vodafone
Minutes
White paper
http://www.openajax.org/member/wiki/WP3_-_Mobile_Ajax
Jon: Any final comments? Do we want to set a final, final date for feedback?
Nikunj: Should we say something about Flash cards for local storage?
Jon: Is this widely used with Ajax?
Nikunj: Not sure. Might be used by widgets.
Andrew: Today I don't think they are available to Ajax.
Paddy: Only local storage access today is file upload via HTML forms.
Nikunj: SQL based storage is becoming available, such as in HTML5.
Paddy: The white paper is mainly about what exists today.
Nikunj: OK to leave it out for now.
Jon: In terms of the final, final date for feedback, we have been working on this white paper for months. How about saying it's done today and immediately turn it over to the Marketing WG for editorial review and publishing?
DavidP: I say yes, let's press ahead.
Andrew: I agree. We set a deadline twice. Today we have a quorum of active attendees. Going once, going twice, gone.
RESOLUTION: Send the white paper to the Marketing WG for editorial review and publishing
Continued discussion of DavidP's email (from last week)
http://openajax.org/pipermail/mobile/2008q2/000163.html
Jon: Let's start at the top and quickly review discussion from last week, but with David present. First thing is about extensibility. We had discussion last week with follow-on email, where we are all agreeing that JavaScript offers easy ability for toolkit developers and application developers to create custom JavaScript APIs to allow convenient functions to access a service or convenient functions to join together services. I promised to update the wiki pages to reflect this, but so far all I have added are red-colored comments that describe what we need to say.
Andrew: Does JavaScript flexibility allow us to pursue a more granular approach to APIs, but without making them too hard to use.
Jon: I agree that we can consider more granular APIs due to JavaScript's ease to create custom wrapper functions.
Andrew: Can we capture this, where we say that we want granular and flexible while still trying to be consise?
Jon: Yes, probably should capture this.
Nikunj: Someone recently had an article that talked about API design. Could reference this.
Nikunj: First order is to have comprehensive but independent modular approach. Second order is convenient to use.
Jon: As a general guideline, I agree. Should this be under objectives or requirements?
Andrew: My rule: can it be tested? If yes, then it's a requirement.
Jon: Probably can't be tested, so that means objective.
Nikunj: Fine as an objective. We pretty much already have it. The main part that is missing is comprehensive. We can't dismiss a use case because it translates into an inconvenient API.
Paddy: Our first objective is a general framework that can define any API. But for those APIs, we can have an aspiration to find a balance between functional scope and usability. Could say that our objective is more limited to make it more convenient and accelerate time-to-market and therefore might omit a use case.
Jon: Yes, the 80/20 or 90/10 rule. We will architect things for extensibility so that the remaining 20% or 10% can be added by the market. Our goal is to drive interoperability for the most common things.
Paddy: The Java community tried to address every possible case. Takes a long time.
DavidP: I agree with Paddy. Need to look at 80/20 and the first 80%.
Nikunj: Then what we need is to be comprehensive about the top use cases. But if you have 2 options, of course choose the most convenient API.
Paddy/Jon: Agreed.
Andrew: Now let's move to the section on application development model.
David: Question to consider: are preinstalled widgets and applications safer from a security perspective, or do we need to cover all three use cases? The Web Runtime is different because it contains network features as a core feature.
Jon: Yes and no. On the yes side, Paddy has submitted a general security model that can cover all of the cases. The preinstalled widgets and applications can be considered as coming from a trusted agent and therefore fit into the security model as someone who can have access to any API because they are trusted.
DavidP: But sometimes the preinstalled software comes from a 3rd party and you don't fully understand or trust it.
Jon: That's the no side. Still fits into Paddy's model. Some pre-installed software comes from trusted agents. Other pre-installed software comes from untrusted agents.
DavidP: The documents should reflect this.
ACTION Jon to update the wiki pages to show that we should try to address all 3 scenarios
Andrew: Anyone disagree with David?
Paddy: All depends. There are all shades of gray. You could lock things down entirely to prevent access and feel secure, but will that be useful for the kinds of things we want to enable?
Andrew: Of course, the answer is no.
Paddy: It's easy to make a secure building that has no windows or doors.
DavidP: Going up a level. Do we need to support all 3 scenarios? I think yes. Are they equally relevant? I think yes. Then the question is whether we can tackle all 3. That's the hard question.
Andrew: We need to highlight the technology similarities.
DavidP: We seem to be in accordance. Let's move on.
Jon: I suggest skipping the multi-origin area as that's another security rathole and move onto the specific API section.
Jon: David's email asks about detailed apis for particular areas, such as getting phone numbers from address book. I suggest that we outline the next level below what is on the requirements list so far. For address book, maybe a single bullet that identifies the sorts of APIs that we think we need, such as query and set. But that's it.
DavidP: OK
DavidP: Guillermo and I can help out and provide more detail. Do you want to link to use cases? Goal for next week is for everyone to flesh out details of requirements and add appropriate use cases. Is it feasible by next week?
Nikunj: I wil try.
Jon: How strict are we going to be about requiring use cases for each requirement?
Paddy: I would vote for allowing common sense extrapolation.
Jon: Do we need a comparison matrix between the features that everyone supports?
Paddy: We are shooting for the common 80% case. For a long list of features, we can look at Java.
Nikunj: Oracle is working on an internal spec for offline with Mobile Ajax, using Gears or equivalent technology. This is future oriented. Can we pursue something in this area.
Jon: OK to do this even if future oriented so long as someone does the work. But of course we need to also finish the common 80%
DavidP: We are also trying to influence the future so future-looking things can be appropriate.
Nikunj: A top request for Enterprises is how to get my app to work when not connected. How do we decide what is in the 80%?
DavidP: Let's see what everyone comes up with. We don't want a process that excludes things. Persistence is likely to be an important requirement for many.
Paddy: Persistence is of interest everywhere, including mobile. Merits discussion.
Jon: One question is whether everyone is just going to implement the features from the HTML5 spec. Will that be the one and only API for the industry?
Nikunj: If you think about it, Gears hasn't caught on much, even with Google's apps. I'll describe an approach where you don't have to agree on persistence or syncing, can instead us existing IETF standards.
Next week
Andrew: API requirements and use cases
