After the WAP Architecture Specification, Figure 2.
This old chapter is here for people who need to program for old (circa 2000) systems that use the WAP/WML standard. A new version of this chapter is available at http://philip.greenspun.com/seia/mobile/.
Among the principles of sustainable online community in the planning section of this workbook, notice that the following are not mentioned:
In this chapter you'll learn how to open your community to users connecting from small mobile devices.
The cell phone connects to your Web server through a service provider's gateway. The gateway translates encoded requests from the phone to standard HTTP GETs and POSTs, fetches the results, encodes the results, and returns the results to the phone. Data are passed between the gateway and cell phone in a compressed binary format, using a WAP-specific set of protocols (i.e., Internet Protocol is not used between the phone and the service provider). The gateway also manages the relatively unreliable network connection to the phone.
WAP content is delivered in Wireless Markup Language (WML) format. WML supports a somewhat different set of user interactions than HTML, and adheres strictly to the XML standard. To serve a user on a WAP device, the Web server needs to recognize that the request is coming from a WAP device and return WML with the appropriate HTTP headers and tags:
The text in bold (above) is what the programmer types, simulating a WAP microbrowser request. Note that in the returned headers and deck from the photo.net server are three "don't cache me" incantations. Your phone and your phone company will take every opportunity to cache a WAP screen, by default for as long as 30 days. Reloading at 10 Kbits per second isn't much fun. As you're developing a service, however, this caching becomes a curse.
bash-2.03$ telnet www.photo.net 80 GET / HTTP/1.0 User-Agent: UP.Browser Accept: text/vnd.wap.wml HTTP/1.0 200 OK Cache-Control: no-cache, must-revalidate Pragma: no-cache Content-Type: text/vnd.wap.wml; charset=iso-8859-1 MIME-Version: 1.0 Date: Sun, 22 Apr 2001 15:29:35 GMT Server: NaviServer/2.0 AOLserver/3.2+ad12 Content-Length: 1179 Connection: close <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <head> <meta http-equiv="Cache-Control" content="max-age=0"/> </head> ...
Here's a simpler return result, of a WAP deck short enough to print in its entirety:
WML documents are designated by the text/vnd.wap.wml
Content-Type and must all be prefaced with tags indicating the XML
version and document type definition. WML documents consist of any
number of discrete page views, or cards. A complete document
consisting of several cards is referred to as a deck. The
main distinction between a deck of cards and a collection of HTML
pages is that the entire deck is loaded atomically. This provides a
better user experience on browsers with small displays on slow,
unreliable networks.
first-page.wml on your Web server and load the example
into a WAP browser. We recommend that you place this file in a /wap/
subdirectory underneath your Web server's page root.
Step 1 -- headers. Your Web server
should provide a means of setting the Content-Type header for the
outgoing response. If you are lucky, the .wml extension
on your source file will be sufficient to alert the server that
the correct content type is text/vnd.wap.wml. If not,
you will either have to register this rule with the server or
explicitly set the headers in a script or servlet responsible
for returning the markup.
Step 2 -- telnet. Test your handiwork by issuing
a GET request for first-page.wml using telnet. With the
possible exception of extra output headers, the server response
should exactly match the example highlighted above.
| Step 3 -- emulator. Install or locate a WAP emulator, either a PC microbrowser emulator or Web-based tool. See the links at the end of this chapter for popular emulators. Load the page again, this time using the emulator. |  |
Step 4 -- phone. Find a WAP phone with wireless Web enabled and load the page again. While expensive, this mode of development has the very important characteristic of realism. Ideally, your development environment will use a mixture of PC emulators and real microbrowsers. [hint: most microbrowsers contain a "Go To" function for typing in free-form URLs.]
HTTP/1.0 200 OK MIME-Version: 1.0 Content-Type: text/vnd.wap.wml <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <!-- This is the first card. --> <card> <do type="accept" label="Answer"> <go href="#card2"/> </do> <p>What is your name: <input name="Name"/></p> </card> <!-- This is the second card. --> <card id="card2"> <do type="accept" label="Answer"> <go href="#card3"/> </do> <p>What is your favorite color? <select name="Favorite"> <option value="red">Red</option> <option value="blue">No, blue!</option> </select></p> </card> <!-- This is the third card. --> <card id="card3"> <p>Name: $(Name)<br/> Color: $(Favorite)</p> </card> </wml>What it might look like on your phone:
First Card
Second Card
Third Card
This deck consists of three cards. The first two prompt the user for
input and the third displays the results. Results are passed between
cards using the document-level variables Name and Favorite. Variable
substitution is effected by prefixing variables names with a dollar
sign ($) and enclosing them in parenthesis. Navigation between cards
is handled with go tasks inside card-level
do elements. The do element provides a
general mechanism for users to act on cards. The type
attribute indicates what kind of action to associate with the
do. An "accept" action occurs when the user
hits the OK button on her cell phone. The go task plays
a role similar to the HTML form element, containing a
target URL and optionally query data and method type. The notable
difference here is that user interface code appears outside
the go task.
x-up-subno=yMrSkytUzuPxQs01_up2.upl.sprintpcs.com
A PC emulator will very likely try to construct a subscriber number
using the hostname of your machine. Here's one recorded from a
session with an Unwired Planet emulator:
x-up-subno=nobody_laptop.grumet.net
What kinds of personalization can you support using this method of authentication? Could you use subscriber number authentication to manage a shopping cart? Are there any security risks associated with this method of authentication? What is the disadvantage to the user, from a convenience point of view, of a WAP service that uses only this method of authentication for personalization, etc.?
For authentication via cookies you need to go back to the form built for Exercise 4 and back it up with a script that generates a Set-Cookie header with an authentication token. We recommend that you make this cookie persistent as typing a full email address is pretty painful on a numeric keypad. Note that on an organization's intranet site you can autocomplete the "@foobar.com" or "@yow.org" portion of the email address for most users.
Background: The Paper Case (1973).
ü will break the
deck (i.e., watch what you're querying from your RDBMS)
if statement in the index.adp, index.pl, or index.tcl
script at the top level of your Web server's page root.
Write down the client's answers to the following questions:
A WAP session is sort of like using an old-style modem-based ISP. User explicitly connects. User waits for connection. User views WAP screens, all the while aware that every second of operation is running up the bill. If the server is slow, the user pays more for the same information. If the user is a slow typist (not too hard to imagine when typing letters on a numeric keypad), the user pays more for the same information. iMode, by contrast, is always-on, like a wired-in computer on a university desktop or a home computer connected via cable modem. A user can leave an iMode page on the screen, follow a link 15 minutes later, and pay the same per-byte charge that would have been paid if the pages had been requested in immediate succession.
In WAP systems, the phone company decides what sites are going to be interesting to users and places them on a set of default bookmarks. The phone company often charges the site publisher to be promoted to its customers. The result? Every WAP system in the US makes it easy to connect to amazon.com and shop for books. A user can type in "www.photo.net" and get a WAP update on the community but it is tedious to type and, though the phone company is raking in 10 cents per minute, the publishers of photo.net are getting nothing. What incentive do the programmers at photo.net have to improve the WAP version of the service? In the HTML world, a commercial publisher can at least take comfort from the idea that every page requested means the opportunity to sell a banner advertisement. But in the WAP world, it would seem the only the phone company and etailers have any opportunity to sustain themselves. DoCoMo, the Japanese company that runs the iMode service, takes a different approach. DoCoMo decided that they weren't creative enough to figure out what consumers would want out of the mobile Internet. They therefore came up with a system in which content providers are more or less equally available. Content providers can earn revenue via banner advertisements or by charging for premium content. When a provider wants to charge, DoCoMo handles the payment, taking a 5-9% commission.
The combination of always-on and non-starvation for content providers has created an explosion of creativity on the part of publishers. The most popular services seem to those that connect people with other people, rather than business-to-consumer amazon.com-style ecommerce.
Is there hope that WAP systems will eventually become as popular as iMode is in Japan? The first ray of hope is provided by General Packet Radio Service (GPRS), being rolled out worldwide in 2001. GPRS takes advantage of lulls in voice traffic within a cell to deliver a theoretically maximum of 160Kbits/second via unused frequencies at any particular moment. GPRS requires new handsets that are equipped to listen simultaneously on both the dedicated circuit-switched connection in use for a voice call and also monitor GPRS frequencies for incoming packets. In practice, GPRS may provide only three or four times faster throughput than existing WAP systems. More important is the fact that GPRS delivers an "always-on" experience similar to that of iMode or a hardwired desktop computer.
As noted above, with GPRS the wireless Internet will become a place that supports simultaneous voice and text interaction. For example, the following scenario can be realized:
There is no evidence that the phone companies outside Japan will wise up to the power of revenue sharing. However, with the introduction of GPRS the wireless Internet will become something better than a novelty. See http://www.rysavy.com/Articles/GPRS2/gprs2.html for more on the subject of GPRS.
SDK's and WAP-enabled browsers are available from
Web Application Programming tools