Mobile Minutes 2008-03-06
From MemberWiki
URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-03-06
Contents |
Attendees
- Andrew Sledd, Ikivo (co-chair)
- Rick Saletta, Wavemaker
- David Pollington, Vodafone
- Paulo Neves, Present Technologies
- Nikunj Mehta, Oracle
- Jon Ferraiolo, IBM
Minutes
Device APIs Use Cases (part 1)
Andy: Jon, you have added some wiki pages.
Jon: Yes, I created a wiki pages for use cases, one for requirements, and one for security. I only added text to the use cases page because that seemed like where we should start.
Andy: Ok to start with use cases?
DavidP: Good idea to get use cases done first. Probably a lot we can provide here.
Nikunj: It's hard to know if we have a good breadth of summaries. Is there a way to verify that we have good breadth or verifying our priorities?
Rick: The only other use case I can think of is the ability to access a video or a song.
Andy: We have until April 30 to decide whether we have a good list.
Nikunj: We need to either prioritize or make sure that multiple pepole have contributed.
DavidP: The use cases page splits things into 3 groups, web widgets, installable widgets, and device-resident apps. But the last two are much the same thing.
Jon: From a technical perspective, yes, they might have the same security implications, but for use cases, these represent different workflows. In one, the user installs. In the other, the device manufacturers decides to include it.
DavidP: Maybe have an installed app category with two sub-sections.
Jon: That makes sense to me. I'll do it after the call.
Nikunj: If we agree on grouping, I'll have more confidence about breadth.
Andy: Let's look at the browser section
Jon: Is this list valuable and interesting? Will the community actually want and do these things?
Andy: Our experience with providers is that this is a key use case. Avoids installation but provides extended services.
DavidP: There is an interesting philosophical question. People usually think about telephony services but it's more about the user data, such as calendar. There are more interesting things outside of telephony. For example, use the camera and upload a photo to a blog. This aligns with Web 2.0. This is all my personal view, not a VF view. Regarding security, want to do the easy stuff to get to the market quickly.
Andy: I agree that's key. Easy to think of phone stuff. Need to provide the user with real benefits. For example, booking your flight and recording your confirmation number. These are the kinds of things you need. But they also point out key security issues.
Nikunj: I agree. Need to target features that are available today. Location is not always available. What are we targeting?
Jon: I would suggest we target phones that will ship 1-2 years from now. Whatever we do probably won't impact existing phones. Therefore, we need to be more forward thinking than backwards thinking.
Nikunj: Yes, but still target features that are likely to be there.
Jon: The generalization of this is to say we need to do a cost/benefit analysis and assign low priority to features that will be difficult for us to do and will get low levels of adoptin, and high priority to features that are easy to do and will get high adoption.
DavidP: What do we want to put into requirement?
Jon: For browser case, I was thinking two simple requirements. Need access to device APIs and need an appropriate security management system.
DavidP: Maybe data persistence requirement falls out
DavidP: Maybe requirement to notify the user
Jon: One aspect of our security requirements would be either user notification or approval of particular attempts to access APIs
DavidP: Would we have a separate framework for different scenarios, browser and installed?
Jon: I want to suspend judgment until we get further in our discussions. Maybe yes, maybe no.
Andy: Let's go to the next section, installable widgets.
Jon: Like David said, it's installable. One question I have is whether the industry will care about anything OpenAjax might say about installable mobile widgets security.
Andy: We will make them pay attention! :-) Either the widget gets full access or limited access. Like a browser, whether something is fully trusted or has limited trust. Fully trusted hosts are granted extra rights.
Andy: With a location-aware widget, it might upload your current location to a web site. This would be great in LA to find a way around traffic, but you have shared some privacy information with that web site. My assumption is that users already give trust to certain sites on the desktop and will do similar on mobile.
DavidP: Aren't all APIs likely to be available across both browser and installable apps? Same issues. User privacy. Opt-in vs opt-out, levels of granularity.
Andy: Probably not different security rights between browser and widget.
DavidP: A web page that you can trust is likely to be the key.
Jon: Good points!
DavidP: Then comes the issue with Facebook. You might trust Facebook but not necessarily the components that might appear in Facebook.
Andy: The key thing with security is what to *enable* versus disable.
DavidP: For next week, we should all attempt to flesh out the use cases. And then start into the nitty gritty about security.
(various): March 20 is a holiday in Europe. Also, week of AJAXWorld.
Jon: Let's skip that week.
White paper
Rick: With the white paper, what's going on. We could take various people's comments and translate into revised text.
Andy: Maybe move to preliminary final draft. That's what we talked about.
DavidP: Need to consolidate and then review
Rich: Need a date to close comments
DavidP: I think we can close comments now. People have had enough time.
Andy: I agree wholeheartedly. Get into a final document state, one final round of reviews, then set a final review date.
(agreement)
Rick: I'll start editing the full document next Monday.
Device APIs Use Cases (part 2)
(agree on a schedule)
- March 13th: use cases
- March 20th: no phone call, people should be working on security implications
- March 27th: discuss security implications, schedule a liaison call with Security TF
- Then 4 more weeks, where we need to
- Define criteria for prioritizing APIs
- Define what APIs we need and prioritize them
