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.

WURFL
WURFL, the Wireless Universal Resource FiLe, is a configuration file that contains info about the capabilities and the features of devices available on the market. For example, if I were to ask you whether a Motorola V66i supports M-Services' Download Fun, would you know the answer? I would...but only after taking a quick look at the WURFL. The answer is yes.

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:

The Gory Details
Let's take a closer look at the WURFL. The first device modeled in the WURFL is the generic. In the unlikely event that a device cannot be matched to any of the devices in the WURFL, the match with the generic will succeed. The generic models all the properties with minimalist values (no support for multiple colors, no MMS, no Java, and so on. Only WAP 1.1 support is assumed). Other devices sort of "derive" from generic through the aforementioned fall_back mechanism.

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,
image_format, bugs, wta, security, storage, downloadfun, wap_push,
mms, j2me sound_format

From Theory to Practice: the WURFL Framework
I now assume that you are convinced of the value of the WURFL as a database of device information, but you may be wondering how much work it is to build applications on top of it, since you will need to actually parse the file and figure out a few things. This is not necessarily a problem. The WURFL framework is not just the data. It also includes tools, utilities, and libraries to parse and query the XML data. The PHP and Java platforms are particularly well represented in this regard, but you can check out the WURFL Web site (http://wurfl.sourceforge.net) to see which platforms are supported.

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.

Conclusion
WURFL is an open-source project created by wireless developers in the attempt to solve a common problem. Using the WURFL is simple and the architecture is sound (as proven by some important deployments throughout the world). On the WURFL Web site, you'll find more information, the software, and, of course, the most recent version of the WURFL.

Source Code

Listing 1

<device user_agent="MOT-V66M/03" fall_back="mot_v66m_ver1" id="mot_v66m_ver3">
<group id="product_info">
<capability name="model_name" value="V66i"/>
</group>
<group id="downloadfun">
<capability name="ringtone" value="true"/>
<capability name="ringtone_imelody" value="true"/>
</group>
<group id="j2me">
<capability name="midp_10" value="true"/>
<capability name="cldc_10" value="true"/>
<!-- limits in kilobytes -->
<capability name="runtime_memory_limit" value="350"/>
<capability name="physical_memory_limit" value="600"/>
<capability name="download_limit" value="600"/>
<capability name="j2me_colors" value="2"/>
<capability name="j2me_softkeys" value="2"/>
<!-- extras above midp-1.0 specs -->
<capability name="phonenumber" value="false"/>
<capability name="motorola_lwt_extensions" value="true"/>

<capability name="j2me_colors" value="2"/>
<capability name="screen_width" value="120"/>
<capability name="screen_height" value="146"/>
<capability name="socket" value="true"/>
<capability name="extra_graphics_api" value="true"/>
<capability name="vibration" value="true"/>
<capability name="extra_sounds_api" value="true"/>
</group>
</device>

Listing 2

<%@ page contentType="text/vnd.wap.wml" %><?xml version="1.0"
encoding="ISO-8859-1"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org//DTD//wml_1.1.xml">
<%@ taglib uri="/WEB-INF/tld/wurfl.tld" prefix="wurfl" %>
<wml>
<card>
<p mode="nowrap">
<wurfl:if>
<wurfl:condition capability="gif"/>
<wurfl:then>
<img src="/pix/logo.gif" alt="Openwave" />
</wurfl:then>
<wurfl:else>
<img src="/pix/logo.wbmp" alt="Openwave" />
</wurfl:else>
</wurfl:if>
<wurfl:if capability="midp_10">
<a href="portal.jsp">Try Java on your phone</a><br/>
</wurfl:if>
<wurfl:ifmc logic="AND">
<wurfl:condition capability="midp_10"/>
<wurfl:condition capability="j2me_colors" relation="GT" value="8" />
<wurfl:then>
<a href="portal.jsp">More Better Java!</a><br/>
</wurfl:then>
</wurfl:ifmc>
<a href="portal.jsp">News</a><br/>
</p>
</card>
</wml>