 |
An Interview with Martin Frost
by Bruce Stewart
11/21/2000
Ever wonder what your Web page looks like on a cell phone? Delivering data
applications and Internet content to mobile devices is one of the hot spots
on the technological landscape right now. One reason this technology is
taking off is because all of the significant industry players joined
together to back a common standard for mobile data, the Wireless Application
Protocol (WAP). Included in the WAP specification are the Wireless Markup
Language (WML), and the WMLScript scripting language, which serve analogous
functions to the Web's HTML and JavaScript.
As predictions concerning mobile Internet use continue to skyrocket (like a
recent
Cahners
In-Stat study that promises 1.3 billion wireless data users
by 2004), opportunities in developing wireless content will grow rapidly.
Now is a great time to become familiar with the tools being used to craft
the wireless Web.
Martin Frost is the author of
Learning WML and
WMLScript, a new book that describes the markup and client-side
scripting languages used for delivering content to wireless devices. Martin
is the head of WAP technology at
Digital Mobility Ltd.
in London, and has been working with WAP since 1998. Writer Bruce Stewart
talked to Martin about the book, WML and WMLScript, and the future of the
WAP model.
- Stewart:
-
Why don't we start with an explanation of what the Wireless Application
Protocol (WAP) is and why it was created.
- Frost:
- WAP is a standard for creating applications to run on wireless devices,
such as cell phones and PDAs. It was created to work around the limitations
of these devices, especially the very small screens and the limited
bandwidth available for downloading content.
- Stewart:
- How do WML and WMLScript fit in to the WAP model?
- Frost:
-
To make it easier for developers to learn the WAP standards, they are
based on a model very similar to the Web, which uses HTML to create
pages of formatted text, and JavaScript to add dynamic features.
WML is WAP's equivalent of HTML. It allows text to be marked up with
paragraphs, hyperlinks, text input boxes, and so on, but in a way that
optimizes the content for small screen sizes.
Similarly, WMLScript replaces JavaScript in the WAP world. It allows
simple client-side checking of input, but is much simpler than JavaScript
and is considerably less demanding on the device.
- Stewart:
- WML appears to be pretty closely related to HTML, so experienced Web
developers should be able to make the jump to WML without a steep learning
curve. What are the biggest differences between the two markup languages,
and are there any WML concepts that experienced HTML coders should pay
particular attention to when learning WML?
- Frost:
- One important difference is that WML is based on XML, which means that
much of the syntax is a lot stricter than HTML. For example, all tag
names in WML are case-sensitive, whereas HTML allows any case.
Another effect of XML is that empty-element tags, which are tags that don't
have an end tag, must be written with an extra slash like:
<br/>
whereas in HTML this would look the same as a start tag
<BR>
A lot of HTML contains syntax errors that are ignored by Web browsers,
but will cause problems for WAP browsers. Many people forget the
quotes around attribute values and miss the semicolons off the ends
of entities, and both of these mistakes will cause the file to be
rejected by most WAP browsers, even though Web browsers will attempt
to ignore the error.
WML also includes several new features that aren't found in HTML,
most notably in its support for interaction. HTML evolved over some
time to include new features: interaction was initially limited to
just hyperlinks, then Netscape added forms with checkboxes, text
input and so on, and JavaScript was added later still. WML has a
different way of approaching these things, which is more elegant
and consistent but may take some getting used to. This new approach
is discussed in detail in my book,
Learning WML and
WMLScript.
- Stewart:
- Could you elaborate a little on WML's support for interaction, and how it's
different from the Web model?
- Frost:
- On a Web page, you've got hyperlinks and form-submit buttons, but
these each have different limitations and look different onscreen.
In WML, the control is separated from its action, so there is a thing
called a "task". This is simply an action to be performed by the
browser, such as going to a new place, running some WMLScript,
and so on. This task is then linked to the actual control--the task
is just another tag, so it's placed inside the control.
This means that you can have a hyperlink which does a POST, a button
which runs some WMLScript, and you can also link these tasks to other
things like a timer that goes off after a certain amount of inactivity,
a particular option being selected from a list, and so on. It all just
helps to make these things more consistent. You learn how to write
tasks once and then it works in all these places.
- Stewart:
- Please explain the "deck of cards" metaphor that WML uses?
- Frost:
-
A Web page is basically a continuous stream of content. You can put
labels into it and jump to particular places, but all you are doing
is scrolling to fixed places in the stream.
WML treats its files as analogous to a stack of cards, each of which
has separate content. Instead of a label merely referring to an offset
in a continuous stream, the label names a card. There is no way to
get from one card to another simply by scrolling--there must be an
explicit link to a card. The idea was to minimize the need for scrolling
by keeping the amount of information on a card small and presenting
information on a sequence of separate cards.
In practice, most programmers don't use this feature as much as
they maybe should.
- Stewart:
-
- Your forthcoming book,
Learning WML and
WMLScript, points out that many of the current WAP browser implementations
are incomplete. What WML or WMLScript features should be specifically avoided
by developers who want their WAP applications to work on as many devices as
possible?
- Frost:
- It depends on what you mean by work.
Some features, such as tables and image alignments, are supported
only by a select few WAP browsers, but usually won't actually break
anything seriously if they are used. The display may look wrong,
but it may still be usable.
A few months ago I would have recommended not using WMLScript at
all, but the situation has improved enormously. A number of
browsers have trouble with some standard library functions, but
it seems that the test suite is gradually doing its job and
weeding out the bad implementations.
The main thing to bear in mind is that you should avoid relying
on the letter of the specification for things like boundary cases
in libraries until the browsers get more mature.
- Stewart:
- What is the test suite, and how does that process work?
- Frost:
The test suite is used for two things. While a WAP browser is being
developed, it can be tested regularly against parts of the test suite
to find any bugs in it. Once it's ready for release, the whole test
suite is run, and this is used by the certification process to ensure
that the browser really is compatible with the standards.
The latest WAP test suite can be found at
www.opengroup.org/vswap1.1.4/.
- Stewart:
- A lot of attention has been given in the technical press to an
insecurity in current WAP gateways that requires encrypted data to be
briefly decrypted at the gateway as it gets translated from TLS to WTLS,
or vice versa. Is this really an important concern, and why or why not?
- Frost:
-
It really depends on who you are. If you trust whoever's running the
gateway, it's not a problem.
Most security experts are very paranoid--it comes with the territory.
They are also invariably perfectionists, and the idea of having this
extra point of weakness is not something they are happy with. They are
interested in designing systems where you don't have to trust anyone,
because even a respectable company can be forced in court or by a
government to reveal private information, and the gateway may be
vulnerable to a cracker.
The other main area of concern is from banks and other financial
institutions, since the main real reason for WTLS is to allow
mobile financial transactions. Most banks don't really understand
computer security--if they did, they wouldn't pay so much to all the
self-proclaimed experts. They do, however, have very strict
procedures about what risks are and aren't acceptable. Their rules
say that the private data must not be accessed by any outside party,
so they don't like the gateway operator having this information
in the clear, even if it's only buried deep in the guts of the
gateway software.
- Stewart:
- Are you comfortable transferring personal data over WTLS?
- Frost:
- I wouldn't use WTLS to send anything actually incriminating, anything
that could cause me real trouble if it was decrypted, just because I
wouldn't want to trust anyone for things like that. I'd be as happy
to use it for sending my credit card number as I would be to send that
number to a Web site using HTTPS. The situation is actually very similar:
If I buy something from a Web site, my credit card number is transmitted
to that site, where it is decrypted and stored. It must then be
reencrypted to send to the credit card clearing company, so there is
still a third party involved.
- Stewart:
- The most recent release of WAP supposedly resolves this security
issue (the June 2000 Conformance Release), but realistically how long
will it take for us to see widespread implementation of this new version?
- Frost:
- It will depend on how much pressure there is to adopt it fast. All the
companies involved with WAP are trying to get exciting content out there
as fast as possible. That has to take priority over a negligible increase
in security which no one will ever notice. If there is serious pressure
from banks or someone, the companies will have to prioritize things
differently.
- Stewart:
- I noticed in your biographical information that you have written a WAP
gateway. Was this difficult? And why write your own instead of using one of
the existing gateway products?
- Frost:
-
Writing a WAP gateway isn't too hard. There are some problems with the
specifications containing errors, and there are some parts where
implementing the specification literally can cause problems, but it's
more an engineering exercise than anything else. Most of the techniques
are fairly standard for using in any high-performance networking system.
Studying the design of a well-written TCP stack or something similar will
give you most of the clues you need.
As to why we wrote our own, we needed the gateway to integrate tightly
with the company's proprietary application server architecture because
we wanted to provide a seamless user experience, with the ability to
reconnect later and pick up where you left off, and so on.
Another consideration was that we wanted access to the source so that
we could fix problems quickly, rather than having to put customers off
with, "Sorry, but our gateway supplier hasn't sent us the patch yet."
At the time we started on the project, the open source gateway wasn't
really in a usable state. We considered it, but decided that we could
do a better job ourselves.
- Stewart:
- What percentage of portable net-enabled devices do you think currently
use WAP (vs. other protocols), and how do you expect that number will
change over the next two years?
- Frost:
-
Most high-end PDAs already support normal Web browsing, and that will
always stay. Most current PDAs either have WAP as an option or the
supplier is working on it. So this fraction will increase.
The situation is different with cell phones. In Europe, there is at
least one phone from every major manufacturer with WAP, and many
manufacturers are working on retrofitting WAP into the older models
that they plan to continue. In the U.S., there are still cell phones
available using Phone.com's proprietary HDML system, and this has
held back the adoption of WAP.
The fragmented nature of the U.S. telecom market doesn't help much,
either. There are many different systems, and still even some analog
networks! All of Europe uses GSM, which means that there is only one
standard for phone manufacturers to contend with, and only one version of
the phone software that has to have WAP integrated into it. These problems
mean that WAP will take longer to take off in the U.S.
As to actual percentages, I really can't comment. Various people
have quoted widely varying statistics on adoption, and I prefer
to leave making quantitative judgments to the statisticians!
- Stewart:
- Fair enough. Do you think NTT DoCoMo's i-Mode, probably the most popular
alternative to WAP, will ever be successful outside of Japan?
- Frost:
-
In its current form, no.
i-Mode is quite closely tied into DoCoMo's network. It uses data
capabilities only found on that network.
I also think that other operators would be unwilling to embrace
i-Mode wholeheartedly and thereby give a large amount of power
and influence to a single company. The advantage of WAP is that
the
specifications are published by the
WAP Forum, a body which
anyone can join--although there is quite a steep joining fee.
A number of companies have made loud public statements that
WAP is dead and i-Mode is the future, but I think most of them
are just desperately flailing around, trying to regain the
initiative. The amount of investment that has been put into
WAP gives it a huge head start on any other system for now.
Finally, i-Mode really isn't all that special. It uses normal
HTML and sound and image files. Apart from the details of the
actual over-the-air communication, the only new part is the
compressed form of HTML that they use. WAP has an equivalent
to this that works for other XML documents, as well.
There are some useful lessons to be learned from i-Mode about
the sorts of applications that are useful and successful in a
wireless environment, but most of these lessons are applicable
to pretty much any system, including WAP.
- Stewart:
- What do you think the future holds for WAP and WML? As bandwidths
increase, do you think WAP will continue to evolve or eventually be
superceded by another wireless technology?
- Frost:
-
Higher bandwidth will not kill WAP, it will simply enable richer
content and a better user experience. It may well be the case that
some parts of WAP, like the special communications protocols
optimized for low bandwidth, will become redundant and can be replaced
by regular HTTP.
The future for WML is more interesting. The WAP Forum has announced
that the next-generation of WAP will be based around XHTML, which is the W3C's
appointed successor to HTML, and based on XML in the same way that WML is.
However, this is still a long way off.
In addition, WML will continue to have a place in cell phones for some
time, even once XHTML starts being used. The fact that WML is optimized
for small screens means that it will continue to perform better than
alternatives, even with lots of bandwidth. Even if it's possible to get
a phone with a multi-megabit link, many people will still want small
phones, because of their convenience.
Just think of the people you know with cell phones now. Even though
there are phones available with big screens, how many people use
them compared to the smaller, more convenient ones? XHTML content
designed for big color screens will come out poorly on these devices,
but WML works just fine!
Martin Frost is the head of WAP technology at
Digital Mobility Ltd. in
London. He has been working with WAP since 1998, and has written a
complete WAP browser and worked on the design of a WAP gateway. He has a
degree in math and computing from Imperial College, London. He spends his
free time reading, playing cricket, designing ever more elaborate schemes
to wire up his home and his car, planning world domination, and trying to
find time to actually do all these things.
|
|
Sponsored by:
|
