DA: But also we'll use
this Google document that I've created as a scratch pad area.
If we find that there are discussions that are going down rat
holes, we can park those in this area so we don't loose
them

JF: Same for issues
that may require oceans to be boiled.

JF: Requests
participants to introduce themselves

<Rhys> Participants introduce
themselves

DA: Presents
introductory slides

DA: Vodafone believes
that mobile access to the web will be the dominant method in 5
years time

DA: Shows
demonstration of the SoonR product. Shows a cool use of Ajax on
mobile devices. Runs inside Opera browser on the device

DA: Things like
transitions are somewhat unexpected on mobile devices. Good
example of the kind of look and feel that can be achieved
without having to write a custom application. All done in the
browser.

DA: Shows Vodafone
application written inside the Ikivo player to provide an
on-device portal relating to the German football league.

DA: My definition of
One Web is that from user's perspective there should be one
information space that is accessible in a very seamless
fashion.

DA: Don't think this
conflicts with Jon's definition given earlier.

JF: The two
definitions are related. From a developer perspective, you can
write for lots of different devices. If you use a server-side
technology you can achieve writing once and letting the server
software adapt

RG: Do a lot of
testing that leads to a browser capabilities database. Detects
the browser and outputs based on it. Server is in PHP right
now, and there is a Rails version under development

RG: Main issues -
first release, building demos, building a community

RG: Open source
project under MIT license. Looking for cooperation.

DA: Summarises the
session and the notes he has made in the scratchpad

DA: Notes the issue of
offline operations and access to low level functions and
security.

DA: Asks if we have
One Web from a user point of view, what does it mean from the
perspective of access to functions on the device?

DB: It's interesting.
When iPhone came out, there was an issue that Google apps
didn't work right on it. Had to create mobile versions. Needs
to be designed for mobile. Two areas are different, because the
capabilties are different

AS: Designers need to
think about One Web. there will be some cases where One Web can
be effective and some where it's not possible, because the
capability isn't there.

DA: Sounds like Frost
takes an approach that includes a server and client component.
How can that scale.

RG: Reason we do this
browser detection is to allow small size of output file. It
only gets the stuff it knows how to handle. Detecting the
browser within the script can lead to issues

RG: Idea was to have
different versions of output on mobile. May use redirection to
get to a mobile version.

RG: Markup is output
in a form adapted to the device. In terms of One Web, will have
different output - same data, but different look and feel.

DA: Consistent with
MWI BP that you need some kind of adaptation and hence device
descriptions

JF: So there is a big
cluster of people who put material on the Web in the long tail.
They are able to adapt and do special versions. Then there are
people who can't afford to do special versions, but can do some
adaptation. The real long tail just want to put stuff up that
just works everywhere without any work.

JF: There are devices
out there that can give a version of the existing web although
the user experience is less than optimal

AS: Most of what is in
the input presentations is also in the papers

VH: Agree with Jon, on
the long tail and the various solutions. One Web uses one
technology. Reuse and don't have to learn additional
technologies for different environments

VH: One web important
to avoid need to learn new technologies. Also need to worry
about accessiblity of content. Can get to it even if not
perfect

<GuidoGrassel> agrees the
distinction between support for full Web technologies and
support for full Web content is important. Only the latter
needs to cope with real-world document complexity on the
Web.

DA: View that in two
ways. One is state of things today. The other is what would we
like the world to look like.

DA: One set might not
be possible now, but might be in future.

James Pratt: The
iPhone is a pretty unusual device. We'll always have the
problem of small screens

<Rhys> Rhys +1 to that

<GuidoGrassel> pls fix the
telco , it is impossible to hear the discussion.

AT: We saw this
problem, and it took lots of work to do the rendering for all
the different browsers

JF: My position was
largely from the perspective of the people developing for the
web. Most people so far have been paralysed. There are now
devices driving this that can access the existing web. But it
might not be usable on mobile devices

JF: Two phases, where
can get to whole web, but it's not necessarily good. Then as
the providers realise that mobile is important, the content
gets better.

DA: Question about the
Japanese market. Users are using e-mail and pictograms. Are
users starting to want access to the same sites that the access
to the existing desktop web

GK: Japanese users
started to use the Web because it was there. Also had phones
before PC. Youngsters better at using phones than parents.
Content providers built mobile sites before PC sites. Also easy
to do in c-html.

GK: Also, Mike talked
about motion sensor in phones. Games support these kinds of
functions. Not all terminals have same sensors. Some
accelerometers, some by camera. Necessary to have abstractions
from the device itself to allow different sensors that can
deliver the same data

GK: Should ask device
vendors to make good abstractions.

<Rotan> GK is pointing out
the general problem of reacting to client-side events, many of
which come from mobile-specific capabilities (or limitations,
in the case of network connectivity).

KH: Long tail is a bit
confusing. Most pages don't have mobile versions. If people
want to get to these new devices, can do it just by making
smaller pages.

KH: Keep it
simple.

AS: Doesn't include
Ajax. So it has a long way to go.

Igor: Latest phones do
support Ajax. Situation is changing fast. Lots of pages do
actually work. Richest applications are issues

KH: Mobile user agents
are getting better

SM: The reality is
that there is a wide variety of agents. Diversity pushes us
further away from the one web vision. Common point is the
server and that's where we need to look. Not adopted well in
the Ajax community.

DA: Is fragmentation
getting better or worse?

[Break until 10:45]

Access to Device Capabilities

JF: Let's get started now!
... This topic has come up many times. Pretty universal. When
Ajax on device, want to leverage features and
capabilities.
... This session is about that subject.
... We will have some lightning presentations.
... Will show you what has been discussed recently.
... Applix first.

[Introductions, starting with Kai H.]

KH: Mobile device APIs. Example,
getting location.
... getting access to address book, file store (for
offline).
... There are problem there.
... We are working on these problems, using our existing Java
implementation.
... Let's talk about JSRs.
... They are specs, standards.
... Am writing plug-in to allow reference to JavaScript library
to access this stuff.
... We are here to promote this idea, and work with standards
bodies to agree APIs.

[Shows slide]

KH: Leveraging Java security
features. Carriers love these.
... Use these to help things happen on the Web.

JF: JSX?

KH: Just a code name.
... More important idea here is leveraging standards.

AA: Question we asked: what can
we do to bring Ajax to people on mobile today?
... Don't want to just target expensive phones.
... Many today barely have a browser.
... Just taking a desktop app to mobile just not enough.

<GuidoGrassel> has a comment
on the presentation: We are saying the mobiles are constraint
devices, some can not support full Web technologies? The spaker
suggests to use Java in addition to Web. Hence, the two larges
run-times on a phone should be running at the same time?! I do
not think this is realistic on other than really high end
phones.

AA: Mash-up of data is
important.
... Broaden defn of Ajax.
... to include things like SVG.

VH: We're trying to simplify
developers life.
... First available is SVG.

<GuidoGrassel> has a comment
on two presentation: Many speakers were arguing that man of
today's mobile devices can not support full Web technologies.
The speakers suggests to use Java in addition to Web. Hence,
the two larges run-times on a phone should be running at the
same time?! I do not think this is realistic on other than
really high end phones.

KH: Want to say that Aplix not
giving you a new way to use Java. Just put script thing in
place to use Open Hub etc.

JF: Local file system, PIM and
GPS access are high on their list.
... Yesterday we had OAA meeting.
... Summarised much of what we've done to date. Looked at JSRs,
MSA and other things.
... Windows Mobile, Opera etc represented.
... Fragmentation: Java initiatives, Opera APIs, and
more.
... Talked about standardisations. Unification. Could take a
long time.

JF: Uses JSON perhaps.
... Only discussed it for half an hour or so.
... We're open for discussion.

KH: I thought of it as
wrappers.

[JF may have disconnected the phone!]

[We're working on it!!]

We're asking Guido's question.

<MikeSmith> [Rotan reads
Guido's question aloud now]

<GuidoGrassel> thinks that
Java and JavaScript neither work together nor is JavaScript
replaceable by Java in any sensible way.

KH: Java already running on
millions of phones.
... Coming up with a way to make it quick and fast.

VH: Timeline issues.

<GuidoGrassel> my point tis
that both run-times would need to run in parallel.

VH: SVG Tiny on phone.
... Is why I was talking about core technologies.
... XHTML-Basic also appropriate.
... We see doing strict browser is good.
... But street HTML and tag soup is too much.

AA: There is class of apps you
want running on the phone all the time, like GPS.

JF: And SAP had their 3
categories of these.

AA: Was thinking of future when
one Web happens.

MS: Guido considering S60, Access
etc running, and Java running at same time, which is a lot for
a small device.

BLR: Solved problem by using Ajax
hub.
... Some ops should not be async, right.
... How is it easier ro standardise message names/payloads,
than just standardising APIs?

JF: Good question.
... Dynamics of industry groups is that some things can be done
in certain groups.
... If industry came together, what options would be have.
Would MS work with JCP for example?
... How much on vendors plates, processes in place, bandwidth
available to them etc.

VH: I think there is advantage to
having generic API.
... Today people do a lot with XML and a handful of methods.
Very extensible.

<GuidoGrassel> Message
passing between what? - I do not think the overhead of message
passing makes sense for things like phone book access.

VH: Difficult to align APIs.

BLR: Dut you still have to
standardise on the payload.

JF: But as Vincent says, you
start with something basic.

BLR: It need extensibility.

Alex: I do a lot of Java library
work. Don't have a lot of leverage here.
... No preference for exposing as API or as tags in
markup.
... If we can't get consensus to get done, and have to do in
JS, then we can do this.,

AB: Thought UWA would solve
this.

RL: Whether you put in markup,
languages, procedural route... if you don't get these in place
then you end up making plug-ins.

LL: As far as browser is
concerned,
... may have same browser on many devices,
... not sure the browser addresses diversity in devices.

<GuidoGrassel> interfaces to
the platform should be JavaScript , no messages, no "markup"
whatever the last should be. But I question the need for
standardization.

LL: You need to address the
device diversity issue.
... Looks like something the DDWG could address.

Alex: Java, SVG, XML are brittle.
HTML is designed not to be.
... Makes it a preferable environment to get this done.

JF: It's an issue I worry
about.
... Need a success plan.
... Get it done in W3C? And when?
... Lots of stuff going on in different orgs. Which has best
chance of success?

DA: When we get into diversity,
we start going on about fragmentation etc.
... There are a small number of capabilities that we could be
thinking about first and foremost.
... These are candidates for standardisation.
... Don't want to get down the road of millions of
properties.

KH: Agree with Alex that browser
is a good environment for this.

YT: To address Alex point re
XHTML or JS tag.
... In browser can extend to use either.
... How to standardise?
... To represent device capability in HTML, JS.
... How to map these to Brew, WinMobile etc.
... How to represent this in tag or JS?

Alex: You train users, and users
train you.
... At first you have to prompt them.
... But over time they adjust.

KH: Carriers are specific about
what users can/cannot access.

DA: Early days to talk about
carriers.
... Will want to have some control over what app providers and
apps themselves can access.
... Esp if they point back to network features. E.g. assisted
GPS where app points back to cell info.

Alex: suggest we not pay
attention to carrier needs.

LL: Not reality of mobile
space.
... Number of interested parties.
... Make solution that shows we address their needs.

<GuidoGrassel> notes that
browsers have a tight sandbox for very good reason. Most of the
browser security issues that are reported are cases of a Web
Appl managing to break out of this sand box. -- What makes us
believe we could open this sand box without causing damage.

YT: You guys (Aplix) use JSR
functionality. How do you do security.

KH: We haven't figured it out
yet. Sandbox. Mediation.
... Might want to sign what object can work in what
domains.

VH: Spent long time in JSR 290 on
those problems.
... Secure app, and secure demployment, a lot to take on.

SK: +1 to Aplix, to not having
too heavyweight a runtime.
... Keep lightweight enough while still being secure.

DA: Joost doing TV app.
... They working on widget.
... Perception that widget with security framework for anyone
to build. Restrict a little bit.
... Simple signing mechanism. Register, sign code with
key.
... Just register as a developer.
... Not sign each app.
... Can revoke developer's cert.
... All apps will then be revoked.
... Lightweight model that could work in Ajax space.
... [Points to Al

<GuidoGrassel> signing does
not solve anything. the infrastructure for getting signed
determines if signing can delivery increased security. No good
solutions for infra that I would know.

[Points to Alex] You sceptical?

[Applause]

[end of session]

Widgets

DA: When I think of widget, think
of all Web technologies, resident on phone, easier to install
than current install process for Java and native apps.
... That's what I think is a mobile widget.
... Has to do with Web technologies.

GG: Widgets well developed.
... Integration with Web-based services on UI level very
straightforward.
... For end user, they appear more app like, more
efficient.
... Hopefully UI is more like an app.
... And hopefully browser chrome is gone too, as this is
confusing.
... Support for full desktop technologies may not imply support
for full Web content.
... HTML5 WG has good principle.
... "Pave the cow path."
... Only do what is necessary.
... Advocate open source to avoid fragmentation.
... Layout issues re small screens is rather over-rated.
... Existing technologies already address this.
... Navigation is a bigger problem.
... Joystick, touch etc.
... Good example of Apply generating mouse events.
... Any kind of best practices doc will have to be written many
times for different interaction methods.
... Have doubts over value of such BP docs.
... Offline work is well on the way.
... Security model is an open issue.
... Protection of user data.
... Different widgets working on device at same time, mash-up,
with different security constraints for each. This is a
challnge.
... We're talking about megabytes of JS in some cases,
... How do we improve JS performance.
... Looked at ECMAScript 4.
... Can't see how Java would replace JS.

Brian: Will be new wave of
devices coming out.
... More like PC devices we're familiar with.
... Much more compact.
... For WiMax network we're building (open IP, end-to-end),
devices certified by WiMax-F
... Will get logo.
... Get on network, ad-hoc. No walled gardens.
... Encouraging an open environment.
... See lot of Web standards as great.
... Hope those things can be re-applied to this new
ecosystem.
... See opportunity for existing Web to migrate.
... Re widgets, think there should be a standard packaging,
file format.
... W3C has outlined what this could be.
... Great if this were standardised.
... Meta-information, security, code signing, to be part of the
file structure.
... Chromeless widget, could be small like a sprite, or take
over screen, or go from widget to widget.
... Or control rendering of page.
... Definitely expect this to happen.
... Offline important.
... No network is pervasive.
... Need to have graceful way to move to different network
states.
... Some really good standards work going on.
... Needs to be more open source implementations.
... Especially widgets.
... For example, a FF plug-in for widgets.
... Seen Google, but not in line with what we see in
WHAT-WG.

DB: Think we share confusion of
what a widget is.

DB: On desktop, shares space with
other things.
... On mobile, it takes the whose screen.
... Problem with widget download is that you don't get instant
update. You need to download the whole app.
... Codesigning doesn't buy you much.
... Sign a widget package, download it, and then it could
download more code.
... Unlike Java app.
... So signing of widget more complex issue.

AB: Let me overview WAF.
... Focus on packaging format.
... What goes in the Zip. The manefest.
... How do you do auto update?
... Non trivial.
... Within scope.
... How far we get, don't know.
... Started one year ago.
... First draft in November 06.
... 20% complete.
... Many empty/open issues.
... Now gone to 30% complete.
... Lot of work to do.
... Working on public mailing list. Invite people here to
participate.
... Want to make these interesting widgets more usable.

DA: Wondering if WAF was looking
at updates. (You answered my question.)
... The way it gets on to the device is more seamless from
user's perspective, than you see with other app installation
processes.

[Dan rants about recent horrible installation
experience.]

DA: Install process for widget is
a hook "Do you want to install? Yes/No" and that's it.

GG: We all know how to find RSS.
You see the icon on the Web page. You click it. Ask if you want
to subscribe.
... Similar approach for widgets.
... Browser can indicate widget related to what's on browser
page.
... This is how I think users will find widgets.
... Browse, find, decide to install.
... Also, any widget is free to emply XHR.
... Combined with storage on device, can become very
powerful.

LL: Getting overloaded with term
"widget".
... Is there something specific about widgets, as opposed to
applications? Or is there a real distinction?

DA: Issues could relate to any
apps on mobile.
... But focus on apps that use Web technology.

[Dan displays definition]

LL: Point I want to make is that
Web as an app platform can address many shortcomings of apps on
mobile.
... The term "widget" as opposed to Web apps is potentially
narrowing.

JF: Some mechanisms growing on
some platforms where there are containers (Yahoo, WinVista,
etc.)
... 1000s of gadgets, just for Google.
... There's a cow path forming around this.

DA: UPS launched huge ad campaign
around "widget".
... There is a groundswell in industry around the "widget"
concept.

Igor: Web widgets are a way to
respond to fragmentation on mobile devices.
... To launch killer app on multiple devices, you'll waste 90%
time doing porting to multiple platforms.
... Widgets provides common baseline.

DA: Though now I notice we also
have widget fragmentation.
... Need standardisation now.
... Otherwise we'll have fragmentation over fragmentation.

Alex: difference between
fragmentation, and things that fail fast.
... Doesn't work at all scenario.
... People getting used to that.
... Have a better shot now of getting it right.

JF: If we have Ajax as runtime
for browsing, widgets etc.
... Widget provides framework for how this gets
installed.
... A simgle deployment path.
... Would work if people supported this one thing very
well.
... Widgets spec could be a way to successful installation.

DA: Spec remains silent on
installation.

AB: Corrent. Right thing to
do.

VH; Think this orthogonal.

AS: Or is it? It may be the
solution.

JF: For long tail of Web, might
be good solution for presentation.
... Also good for apps, as we've been discussing.
... Solving unification problem.

DA: Look at current situation,
apps written across many many platforms.

<GuidoGrassel> thinks that
providing multiple run-times on a device is motivated to
address the use cases and preferences of different developer
communities.

<GuidoGrassel> The community
of Web developers is particular large.

KH: Agree with Larry.
... HTML5 used to be called Web Applications.
... Encourage people to join.

YT: In terms of Google widgets,
residing on server. Need to make distinctions.

BM: One is end-user view.
... Think back. "Ajax" applied to much.
... Marketing benefit of using "Ajax" was inestimable.
... So think of value of "widget".
... We're also looking into the technical definition.
... Separate marketing and technical issues.

DA: Agree.
... Propose "midgets".

[Laughs]

DB: On phone the Apple weather
thing is seen as an application.
... But on the Apple desktop the end-user thinks of it as a
widget.

JF: Developers would probably
like it if we made it easy for them to be cross platform.

["One Widget"]

GK: Re weather widget,
... Widget is not the focus of your attention.
... Whereas on mobile device, it has your focus, so it's seen
as an app to the user.
... On iPhone there is no difference in starting widget or
browsing. All full-screen experience.
... Think destop widget is a background app.
... Never the case on mobile.

GG: Think there is no difference
between widget and browser.
... Widget visible on home screen.
... But no wait for download.
... Just tap on the widget and it runs.
... Better user experience.
... Widget gets prime real estate on the UI.

DA: Are widgets part of MWeb in
Korea?

Kyeongwoon Lee: Yes. Much use of widgets by
Korean users.

scribe: Various support facities
by carriers.

DA: More fragmentation.

MW: Everyone has widgets. No
dominance in the market.
... MAybe now is time to join Art's group (WAF).

[Break for lunch]

Role of server-side adaptation

[Stephen Maryka doing demo of ICEFaces]

[Sean Patterson getting projector set up
now]

SP: Sean Patterson, RH: Rotan
Hanrahan, RL: Rhys Lewis, SM: Stephen Maryka
... We have a content-transformation server product
... here to talk about issues we see with
content-transformation and Ajax
... typical thing that CT servers do is to transform HTML,
CSS
... that is fairly straightforward to handle
... dealing with limitations: screen size, markup-language
support (e.g., WML instead of HTML)
... a lot of browsers on devices have limited JS support
... though we are starting to see more that have JS
support
... but for the most part, as far a CT servers, issue is to
figure out how to deal with complex JS interaction in content
delivered to devices with browsers that don't support JS
... For devices with high-end browsers, you just pass through
all of it as-is.
... for devices with more limited support, you have to figure
out how to deal with it.
... Requires much more granular information than just "does or
does not support JS"
... Another approach is to put some sort of custom client
on.
... Basically, need the ability to update just parts of the
screen.
... Novarra is interested in knowing just how prominent this
Ajax on mobile devices thing is going to be.
... This workshop has made me realize that is does have a
future.

[Rotan Hanrahan steps up]

RH: The ideal world: Content
Resource -> Web Presentation
... except that is not the Real World
... but there is a Proven Solution that relies on content
adaptation using static and dynamic delivery-context
metadata
... Solution: Adapt.

[Rhys Lewis steps up]

RL: "Mobile Ajax and Application
Adaptation"
... The point is to make it easier for content
providers/developers to do this stuff.
... W3C Ubiquitous Web Apps group is looking at some of these
issues.
... Adapt the application logic also
... using a declarative model
... need policy or "styling" for that application
behavior
... translate the author's abstract UI into a concrete UI
... we have the possibility of not only programming-free
applications, but also markup-free applications

RL: We do things like varying the
JS we deliver to a particular device based on what browser is
running on that device.

Kai: Is content adaptation
injuring mobile ajax?

RL: What Rotan and I provide sits
on the origin server.
... Sean's/Novarra's solution is in the middle.
... in the Best Practices working group now, in the Content
Transformation group, we are working on some guidelines,
targeted for publication in mid- to late-November
... to provide guidance on how Content Transformation proxies
-- the adaptation servers in the middle -- to provide guidance
on how that should behave

RH: Another important point is to
provide metadata in the Ajax that will assist in determining
what can/cannot be changed.

What new standards efforts do we need?

AR: Our position is that the Web
works
... and that you don't need to do a lot of adaptation
... we support any effort to give us better access to device
capabilities

DC: I agree with what Jon said
about One Web earlier
... the biggest problem we are dealing with is Mashups
... the browser did not anticipate mashups
... which creates security problems
... we need to get that broken browser security model
fixed
... browser makers have not been able to go forward without
consensus
... but the Google worker-pool solution is one exciting recent
development in this area
... but we have to wait for IE6 to die
... on the other hand, in mobile, because of the shorter
longevity of mobile devices, we have quicker turnaround on
[getting newer browsers deployed on handsets]
... [DC made statement that mashups are one of the most
groundbreaking changes to come in many years]

AS: Fragmentation remains a
serious problem
... and fragmentation will get worse before it gets
better
... problems of timeouts needs to be considered, as well as
mobile data-pricing models
... service discovery is also quite different on mobile
devices
... Also, turnover and replacement rate of mobile handsets is
decreasing
... Solution requires us to Keep the Door Open, refactor/refine
problem statements

[Dan Zucker steps up]

DZ: "How to Standardize for
Mobile"
... Of course we need mobile subsetting.
... it is a simple question of device physics
... The desktop standard is a moving standard also
... Typical way is to produce a "Tiny" or "Basic" subset of
specific standard
... We propose instead a range of well-defined profiles between
the "Tiny" and "Full" standards

BM: We have seen one thing come
out: The only thing you can do is to set a minimum baseline,
even though it is a moving target.
... the baseline is a market-consolidation activity
... What Dan Zucker proposes is only going to extend the
problem
... Instead, tell the market that the full standard is indeed
the goal.

AR: For Dojo, we are just
dropping IE stuff
... we should be demanding that the device makers give us the
full web on devices

BM: OMA Browsing Enabler 2.4
includes XHR

AB: CPUs on devices have now
caught up

JF: The OpenAjax Alliance just
started its Mobile task force in August

BM: Standardized security
mechanisms should be on the list.

DC: What we need is a security
model that encourages cooperation under mutual suspicion.
... I think Gears provides us the discipline in which we can
solve that.
... We are loading modules but they are not really modules
because they are not contained.
... The security model in browsers has never been good, but
mashups have amplified the problem.

LL: People don't log into their
mobile devices.

DC: It turns out that the
ECMAScript language cannot be repaired in this regard.
... What Gears does shows us is a way to run multiple
instances

Yong Tian: Another way to deal with this is
build smart caching into browsers

scribe: and we should be
approaching this by listing out the existing problems first,
and then looking at what possible technologies we can use to
address those problems.

Gideon: Most of what we have
talked about doesn't consider at all is applications that
integrate voice use of the handset with browsing and with web
applications

JF: Standards activities usually
do poorly when inventing.

BM: Market creation vs. market
consolidation.

Education and evangelism

JF, DA: Acid2 Test and CSS Garden are examples
of efforts that have been important in raising awareness of
compliance with CSS standards.

BM: Those were successful in part
because they were simple.

DA: CSS Zen Garden is great
because it allows/invites third-party designers to
contribute/participate

Howard: One thing might be, take
a set of syndicated feeds, let developers loose to see what
they can do with those [as far as building mashups]
... for CSS Zen Garden, it enables consultants to
demonstrate/showcase what they can do
... so maybe start out with 10 or 20 developers build some
demos, set them up at the site, then open it all up to
participation from other developers

AB: We must be careful about
seeing "getting better browsers on handsets" as a
solution.
... there are economic reasons that drive the what applications
get deployed on particular devices
... we will *always* have lower-end devices with browsers on
them

DA: Do we need to come up with a
standard that specifies what a "Web 2.0"-capable device is?

BM: At least part of this is the
DD and UA profiling and other work that goes on in the
W3C
... which in part depend on static information about what
browser is installed on the device
... Some users now download browsers to their handsets.

Rocco: Sometimes it's a good
thing to have a separate device/environment to develop apps
in

Wrap-up comments

Wrap-up comments: Standards are important part
of the solution (and also a big part of the problem) ... APIs
and mashups are important pieces ... Moore's Law will have a
significant effect ...

scribe: let's do the work in
current working groups, not start new ones ...
... it doesn't look like next steps have been addressed today,
and I think we need to talk about next steps ...
... It's been interesting to see discussion of coupling between
Javascript and Java on mobile devices ...
... Good to have heard about what expectations are for devices
makers, in terms of browsing requirements ...
... Was good to discover some commonalities ...
... Get involved in standards activity at W3C and elsewhere
...
... the problems I'm looking at will not find solutions in a
standards committee ...
... great to see people looking at the unique features of
mobile devices -- not just looking at them as a poor cousin of
desktop PCs ...

DA: In general, the place to
follow up on work related to this topic is through the W3C
public mailing lists, the OpenAjax Alliance ...
... the only barrier is in how many e-mail messages you are
capable of reading each day ...
... But specifically, we will of course be producing a workshop
report.
... watch http://www.w3.org/2007/06/mobile-ajax/
for details

Much thanks to Microsoft for hosting, and to
Steve Marx in particular for helping with logistics and
troubleshooting.