The Wireless Emperor Has No Clothes
The Wireless Emperor Has No Clothes
By: Peter Roxburgh
Dec. 26, 2000 02:13 PM
Six months ago I convinced my father, a committed technophobe, to connect to the Internet; he wasn't impressed. Last month he bought a WAP phone; he still wasn't impressed. What is impressive is his new-found knowledge of HTTP error messages that could shame many a developer. He's now conversant with errors 400 through 404, a connoisseur of "Internal Server Errors" - and merrily feasts on "Content Type Unacceptable."
My father's error-message mastery isn't a symptom of the WAP protocol itself failing: it's symptomatic of the failure of WAP's implementation. A lot of big sites, really big sites, are failing to deliver content to some of their visitors; this is immensely significant. Revenue is lost every day, and consumers become disillusioned, yet the underlying problems remain unexposed and unaddressed. Now's the time to expose and address them!
WAP ensures that content is delivered efficiently, so why is there a
problem? Initially the developer's role should be scrutinized: many are
creating sites that simply don't produce renderable results. Why is this?
Simple - many WAP developers were Web developers yesterday. I harbor no
grudge against Web developers, but
To appease ex-Web developers and ward off any impending lynch mob, it must be said that a dirty trick has been played on them. There's seemingly a mischievous imp in the camp, namely Phone.com. We're all familiar with vendor-specific extensions (look no further than Microsoft); well, Phone.com has vendor-specific extensions. However, there are so many extensions that we're left wondering whether WML is purely an extension of Phone.com's own markup language. Thus a site optimized for Phone.com browsers, utilizing their extensions or markup depending on perspective, may not render on other vendors' browsers; if it does render, the usability of the site is often compromised.
Don't pass judgment prematurely, however. Phone.com existed long before the WAP Forum was conceived and at the head of a wireless storm in the U.S. it can be argued their loyalty lies with market share, not with the WAP Forum.
Without digressing needlessly, you may wonder why Phone.com was a founding member of the WAP Forum. The answer, arguably, may be deduced through a roll call of the WAP Forum's board of directors: they are representatives of Phone.com, NTT DoCoMo, and most major network operators and handset manufacturers. Inevitably, these companies can't allow a wireless standard to evolve that they have no influence or control over. So forget arguments about which technology is superior or will prove the victor in some twisted wireless battle: their futures are inexplicably linked.
Returning to WAP's implementation, the WAP gateway marks another serious failing. A gateway is an inevitable component bridging the wired and wireless worlds. NTT DoCoMo's i-mode service uses an i-mode center residing within NTT DoCoMo's network; WAP on the other hand uses a WAP gateway that any individual or organization may operate. Thus, due to the inherent security risk of gateways in the public domain, a business serious about security must operate its own WAP gateway. Unfortunately, commercial gateways incur a high cost per user, often making it uneconomical to operate a service requiring an acceptable level of security. One solution is open source gateways such as Kannel, still waiting for Linux to overthrow the mighty Windows empire.
If you're a business owner, or director or provider of capital, sorry,
but the "WAP levy" escalates beyond the gateway. The WAP Forum thinks -
or at least once thought - that WML is a pretty good idea; a thousand techies
would agree. However, they've all missed the point: a technically perfect
solution is a bad solution
To summarize, millions of business dollars are being wasted on unnecessary
development. Did anyone stop to think through the cost consequences of
issuing the WML specification? i-mode, although a terrific success,
is inadequate for adoption as a de facto standard. Technically, it's no
more than a brand; NTT DoCoMo could launch a WAP service tomorrow, in Europe,
and label it i-mode. In terms of its Japanese implementation, it exists
in a monopolistic environment. That's not to say it doesn't have competitors
- it does - but they adopt alternate technologies. i-mode content is delivered
from standard Web servers but passes through an
Another technology recently highlighted as a WAP successor is Java. This isn't possible, though, as Java doesn't offer an alternative to WAP, WML, or C-HTML; it's implemented to provide increased client-side functionality as opposed to being a markup or protocol. However, it would provide a mechanism for delivering the functionality many wireless sites lack. With Java, for example, serious game-play becomes possible; so too does high-level client-side encryption. If utilized, Java could complement, as opposed to replace, any of the existing wireless services.
It should now be apparent that the main wireless standards and services are flawed in either their implementation or their underlying structure. And debates on which of the current technologies is superior or will become the de facto standard are naive and simplistic. What's required is for the WAP Forum (or any company capable of global market domination) to introduce a new standard, one that supplies a unified markup language that offers environment-specific functions and a simple but structured syntax, and is optimized for the wireless world. Furthermore, the wisdom of independent gateways should be reassessed; as with so many other facets of mobile technology, perhaps they should be placed solely with network operators.
Finally, we as developers, consultants, or business owners should consider where our loyalties lie: with our companies and customers, or with flawed implementations of proprietary standards?
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week