[OpenAjaxMobile] Minutes from 2008-03-06
jferrai at us.ibm.com
Thu Mar 6 12:30:47 PST 2008
If there are any errors in these minutes, please say what corrections need
to be made.
Mobile Minutes 2008-03-06
Andrew Sledd, Ikivo (co-chair)
Rick Saletta, Wavemaker
David Pollington, Vodafone
Paulo Neves, Present Technologies
Nikunj Mehta, Oracle
Jon Ferraiolo, IBM
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
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
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
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
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
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.
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.
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mobile