Belated apologies, but we had a technical crisis that demanded my
attention.
I was hoping to join the meeting to draw attention to developments in
the DDWG. We're close to an API to access device information (e.g. the
kind of stuff held in WURFL) and that would be beneficial to anyone
considering automated adaptation of Ajax applications to the
abilities/limits of a mobile context. It's only just coming together
now, and we expect to be ready for formal publication after our meetings
in Korea next week.
If you are interested, check out the editors' drafts, linked from the
top of the DDWG's home page:
http://www.w3.org/2005/MWI/DDWG/
Again, sorry about my absence. I hope that my earlier contributions to
the sandbox have helped in some way, and in future I should be able to
contribute properly. Meanwhile for the next week or so I'll be busy
dealing with the matters in Korea.
---Rotan.
From: mobile-bounces at openajax.org [mailto:mobile-bounces at openajax.org]
On Behalf Of Jon Ferraiolo
Sent: 27 February 2008 20:00
To: mobile at openajax.org
Subject: [OpenAjaxMobile] Minutes from today's phone call 2008-02-27
Mobile Minutes 2008-02-27
URL: http://www.openajax.org/member/wiki/Mobile_Minutes_2008-02-27
<http://www.openajax.org/member/wiki/Mobile_Minutes_2008-02-27>
Attendees
* David Boloker, IBM (co-chair)
* Andrew Sledd, Ikivo (co-chair)
* Rick Saletta, Wavemaker
* David Pollington, Vodafone
* Paddy Byers, Aplix
* Rich Thompson, IBM
* Paulo Neves, Present Technologies
Minutes
Device APIs
Jon: Vodafone hosted a meeting in Barcelona at 3GSM/MWC with about 20
companies to talk about Mobile Ajax. It was the second such meeting. The
year earlier, we decided that the industry needed to have a workshop on
Mobile Ajax, and that happened in September, hosted by W3C and OpenAjax
Alliance. At the September meeting, one of the critical areas that was
identified was to open up device APIs to the Web Runtime. Since then, at
OpenAjax, in this committee, we did a bunch of due diligence on what
exists today and captured it on a long wiki page. Now, the meeting two
weeks ago. At the meeting we discussed next steps. There were people who
felt that we needed to move aggressively on an industry basis to develop
standards and there were people who were on the other extreme and felt
that we should let things shake out in the industry and then look to
codify what exists. I proposed a middle ground approach where the
industry gets together in an intense, short-term exploratory effort to
articulate use cases and requirements and describe the key security
issues. I suggested an arbitrary date of April 30, 2008, as the end
point for the exploratory efforts. At the meeting and in subsequent
discussion after the meeting, a good number of people felt this was a
good approach.
Andy: What would be the nature of the use cases?
Jon: I was thinking we would describe a set of use cases at a
high-level. One example would be a search web page that might leverage
the current location API of your phone to create a more personalized,
location-aware set of results. Another example might be a search web
page that returns a phone number, and if it has access to the phone
dialer API, then an icon might appear next to the phone number that
would allow one-click dialing to the number. Also, use cases for widgets
and installed desktop applications. But quick descriptions of scenarios.
Jon: At the meeting, I also proposed a strawman technical approach for
how the industry might pursue a unified technical approach. Before I
describe this strawman, let me first say that our thinking is that this
strawman will be put aside for a couple months as we articulate our use
cases and requirements, and then brought back and looked at again after
April 30, to see if the strawman is a good match for the use cases,
requirements, and security issues that we develop. OK, here is the
strawman. I proposed that OpenAjax launch an open source effort to
develop a simple shim JavaScript APIs for things like access to
location, access to contact list, access to email, access to phone
dialer, etc.. Our JavaScript shim doesn't do anything, but underneath
the shim, other JavaScript would plug in to map our shim APIs to other
APIs that hook up to resident services. There might be a provider plugin
that maps our shim APIs to other JavaScript that integrates with J2ME
MSA. There might be another provider plugin that maps our shim APIs to
other JavaScript that integrates with Windows Mobile.
(some other discussion)
Jon: Any objectives to the proposed intense effort between now and April
30?
Paddy: From our point of view, this is a good way forward. On the open
source area, we would be happy to work on the shim or work on
implementations that go to the device area. Are you aware of Rococo? I
have talked with them about joining OpenAjax Alliance. They helped to
lead the Java Bluetooth spec. They are an example of a company that
might help the open source effort focused on one particular API area.
Jon: Great to hear.
Andy: This proposal is along the lines of what Ikivo would like to see
happen. Ikivo volunteered me to be co-chair largely due to our interest
in seeing this effort move forward.
Jon: I created 3 new wiki pages to capture our work on use cases,
requirements, and security concerns. Right now those wiki pages are just
shells. I would like to have a call-to-action for people to fill out
those wiki pages between now and April 30.
Jon: Is everyone OK with weekly phone calls between now and April 30 to
work on the device APIs? I talked with some other companies, and they
said they would be willing to call in each week.
(general agreement with weekly phone calls)
Rick: What impact will this have on the white paper?
Jon: We will be doing two things at once. I am hoping that after today's
phone call, we will be able to make progress on lots of white paper
issues via email, but we shall see.
(discussion about phone times)
Resolution: Weekly phone calls at 9amPT, noonET, 6pm Paris each
Thursday, starting March 6.
White paper
Title
Jon: It looks like only DavidP and I have made contributions lately.
Anyone else? (silence) My contributions have been to go through some of
the sections and propose new text that attempts to address the feedback
comments. Can we start with the title?
(various opinions about the title. most people are flexible. question
about whether we have enough meat to call it a developer's guide. jon
thinks yes, but only if people agree with some of the meat he has
written for other sections)
Resolution: Title = "Introduction to Mobile Ajax for Developers"
Tips for developers
Jon: I think it would be good to jump to the meat. In trying to figure
out a good way to organize this section, I thought it would be good to
have subsections based on the challenge area, such as small screen size,
and then propose techniques that are available for addressing the
challenge.
DavidP: Exactly the kind of content that we would like to see
Paddy: This approach is better than the previous approach, which was
more intense and pessimistic. Better to describe things to think about.
Jon: I am only about half-done with finishing a strawman initial writeup
for this section. If this is a reasonable approach, I can finish the
other half.
Rick: What is there is essentially an outline for filling out the rest
of the paper.
Andy: What can others do to help?
Jon: I might have left out one, two or three major challenges. If so,
add a new subsection. I might have left out an important technique
within a particular subsection. If so, add that technique. And there is
always improvements with wordsmithing.
Paddy: To be devil's advocate, there are a bunch of considerations, and
yes already know that. My problem is finding more detailed information.
For example, WURFL would help me understand device issues.
Jon: Yes, I agree, and we should provide some additional detail and
links to important resources, such as WURFL.
(question about whether we need to provide complete and comprehensive
info)
Rick: OK if the 1.0 release provides good value but doesn't provide
complete answer. We can always update the document.
Jon: One additional detail I thought made sense was to talk about the
iPhone viewport. Everyone know what that is? (no one does, so jon
explains)
DavidP: One emerging industry standard is quarter VGA, 320x240. Half of
the devices coming up support that profile. iPhone doubles one dimension
to 480.
Paddy: But people need to know. W3C says if you target a particular
low-res, something like 220x???, you get 95% of the devices. Good to
provide some sort of measure.
DavidP: Good point.
Paddy: If I'm targeting an iphone, go here. If I'm targeting more
devices, go here. Let developers choose their target, but help them with
links relative to that target. But if you want to discuss the iPhone as
the state of the art today, then explicit information about the iPhone
would have a role.
Jon: Agree. iPhone should be a small part of the document, but worth
pointing out at particular points.
Paddy: Agree.
Intro
DavidP: I think the proposed text is good.
Andrew: Brief, which is good.
Characterizing...
(no proposed text, no comments, so skip to next section)
In practice
Jon: I think the train example is good, but we need more. It talks about
the widget case. We also need browser case.
DavidP: Can we use the Google/iPhone example that Dave Burke showed in
Barcelona?
Jon: Yes, that's a great example of Ajax.
Jon: I can take a crack at writing up Google as an example.
Andrew: Remove train example or augment?
Jon: I'm thinking the train example shows the use of the Web Runtime as
a widget.
Andrew: Sounds good.
DavidP: Is the objective to show how it exists today or how cool it's
going to be?
Jon: I think we want to reflect both evidence that it already exists
today but make sure users understand how cool it's going to be
Andrew: iPhone shows both evidence and examples of how cool it's going
to be
Next steps
Jon: I'll work on the WP between now and next Thursday to finish up more
sections. I'll send email as I make progress so people can review.
Please everyone else contribute also, particularly on the tips for
developers section.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/mobile/attachments/20080228/3610b58a/attachment-0001.html