Welcome to the WURFL
Welcome to the WURFL
By: Luca Passani
Aug. 20, 2003 01:20 PM
Creating a wireless application that works on as many devices as possible is not difficult, it's useless! If you invest a huge amount of resources today, chances are that a new device will ship tomorrow and you'll need to tweak your application again...unless you use WURFL and its framework.
Fragmentation of the Wireless Platform
Periodically, we are reminded that this or that committee [in W3C/OMA/JCP/Pick your favorite] will fix that for the [J2ME/WAP/WAP-Push/Pick your favorite] technology. Unfortunately, new technologies have been popping up faster than any committee ever fixed anything. After all, if you consider that device manufacturers are all about differentiating (and you consider human nature), it's not surprising that good intentions vanish along the road and all you get is fragmentation: standardizing can be like trying to swim upstream.
While the fragmentation problem has been bugging everyone
from the beginning of time (which for wireless is probably 1997), the
industry has failed to give an effective solution to the problem. If
I had to speculate about the reasons for this failure, I would
probably name three things:
In this situation, it was only a question of time before the ones who need to make wireless work, the developers, would come up with something that did just what they needed.
Does a Nokia 3510 come with a built-in camera? The answer is no. Thank you, WURFL.
While the WURFL file itself is intelligible to a human (or at least a programmer), this is hardly its main use. Developers use the WURFL to figure out device capabilities programmatically and to serve different content to different devices dynamically, depending on the capabilities of the device accessing the content. This is commonly referred to as multiserving a wireless application.
It is accurate to regard the WURFL as some kind of universal database containing info about all known wireless terminals. One requirement is that such a database must be accessible on all platforms. This is why we chose XML for the WURFL.
The WURFL contains a list of <device> elements, each one representing a family of devices (and not necessarily a unique device). At the time of this writing, the WURFL contains over 1,500 devices and over 300 modeled properties (capabilities). It should be noted that WURFL also catches software subversions, which explains why there are so many devices.
At this point, the technologically savvy reader may suspect
that the WURFL is a pretty large file. This is not the case. A
mechanism called "fall_back" keeps the WURFL size down a couple of
orders of magnitude (350 kilobytes at the time of this writing). More
about this later after we have answered some questions:
- WURFL is all about open source. The WURFL itself is just data and lawyers tell us that, as such, raw data is not copyrightable.
- The software around the WURFL, on the other hand, has the license that the creator has assigned to it, but we are always talking open source of one kind or another (GPL, Public Domain, MPL, and similar).
- The short answer is: nobody! You'll have to trust the community of programmers who populated the WURFL by observing the behavior of those devices and reporting what they saw to the WURFL maintainer.
- There's a long answer to the same question that's probably way more interesting to you: paradoxically, the lack of a formal validation process for the WURFL data has several advantages. First, the IP-free nature of the WURFL keeps people contributing data in the interest of the community. Second, if some of the data in the WURFL is wrong, but nobody realizes it, then there's not much of a need to fix that specific piece of data.
- Better yet, if you realize that some of the data in the WURFL is inaccurate, you can go ahead and fix your own copy of the WURFL without waiting for anyone to fix it for you (it takes Notepad and five minutes to do that. This ability to update the data source so quickly and easily is one of the most popular features of the WURFL).
- Of course, in that case, you are more than welcome to drop us a note to tell us what to fix. This basically means posting a message on the WMLProgramming mailing list on YahooGroups at http://groups.yahoo.com/group/wmlprogramming/
- They exist and they are expensive. Believe me.
The Gory Details
Consider a new device. No matter how new and innovative that device is, chances are that 90% or more of the software running on that device is the same as some other device from the same vendor. For example, the differences between the WAP browsers of Nokia 7110 and Nokia 6210 are negligible. Same goes for the WAP browser of Siemens C35 and Motorola T2288, since both devices run the same version of the Openwave browser.
Exploiting this fact is a huge advantage when modeling the capabilities of different terminals. We can now define devices in terms of families and subfamilies. New devices will inherit the capability values of their families by default, while specific differences can be modeled as a delta by overriding the inherited values that are not accurate. This is what the fall_back is all about. Given a specific device and a capability name, the WURFL either declares the corresponding capability value or lets you climb the heritage chain until a device that declares the value for that capability is found. In the worst-case scenario, you'll find the generic device.
Listing 1 shows a WURFL fragment that makes the point (Motorola V66i, J2ME MIDP1.0).
The user_agent attribute is the string that the device uses to introduce itself to the application or the server that runs the application.
The ID attribute is assigned by the WURFL maintainer and uniquely identifies each WURFL device element.
The fall_back attribute contains the ID of another element. This is, in practice, a pointer to another element from which the current element inherits its properties. The WURFL framework can track the value of a given property by following this trace and recursively querying each device.
If one day Motorola were to introduce a new version of the V66 that does, say, MMS, this could be modeled very simply by defining (i.e., overriding) the capabilities for that device while falling back into the device shown in the previous listing for all the capabilities.
As mentioned, the fall_back mechanism keeps the WURFL much smaller than the matrix of devices and capabilities it represents.
Capabilities are divided by groups. This is purely to facilitate human reading, since capability names are global and cannot be repeated in different groups (smart developers like to keep their frameworks simple). The list of groups available in the WURFL at the time of this writing is:
product_info, wml_ui, chtml_ui, xhtml_ui, markup, cache, display,
From Theory to Practice: the WURFL Framework
Here's a look at WURFL support for the Java Enterprise Edition. There's a J2EE library that exposes a really simple API to query the WURFL (for example, given a user-agent and a capability name, the corresponding value is returned). On top of the API, there is a JSP tag library that makes it really simple to deploy WURFL application JSP. The tag library is much simpler to grasp than a servlet, so this is what I'll use to illustrate a practical use of WURFL.
Imagine you need to build a portal that offers access to different wireless technologies (WAP, J2ME games, and cool color J2ME games, just for the sake of this example).
Listing 2 will link all the services available on your site, but it will make sure that only the devices capable of handling that content will display links to the services.
The page in Listing 2 will render differently depending on
the capability of the device requesting the page:
This is shown in Figure 2. Of course, what is important to you is that, if a new device enters the market, you will not need to change your application, but just update the WURFL to keep your application optimized.
<device user_agent="MOT-V66M/03" fall_back="mot_v66m_ver1" id="mot_v66m_ver3">
<%@ page contentType="text/vnd.wap.wml" %><?xml version="1.0"
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