What's cool about the WURFL? Let's say that I have convinced you that a configuration file (or database of device capabilities, which is basically the same thing, just depends on how you look at it) is a good idea, but you suspect that such a file may soon become large and hard to maintain. After all we already have 400 or more devices times 100 or more capabilities. The matrix is pretty large and it will only grow larger. To make things more complex, each device may have several subversions (often corresponding to different version of the firmware). Building such a huge matrix is not necessary, though, and this is where the WURFL is smarter than other solutions. Consider these facts: browsers are different, but they also have many features in common with one another. browsers/devices coming from the same manufacturer are most often an evolution of the same hardware/software. In other words, differences between, say, a Nokia 7110 and a Nokia 6210 are minimal. devices from different manufacturers may run the same software. For example, Openwave Systems provides the browser to Siemens, Motorola, Alcatel, Mitsubishi, Samsung, Panasonic, Telit and Sagem...just to name a few. exploiting these assumption allows the WURFL to be: very compact and small as compared to the complete matrix very simple to update. The WURFL is based on the concept of family of devices. All devices are descendent of a generic device, but they may also descend of more specialized families. A device which identifies itself as (user-agent) "SAMSUNG-SGH-T100/1.0 UP.Browser/5 (GUI)" is an implementation of the GUI browser by Openwave and, of course, also a descendent of the generic browser. As a consequence, as soon as such a device is released (or, we should say, as soon as someone detects its user agent hitting a site), we can safely add it to the WURFL and state that it is a descendent of the "upgui_generic" family. This will let that phone inherit all of the capabilities of the family of the Openwave GUI browser even before that device is actually tested by anyone. This mechanism, called 'fall_back', lets programmers derive the capabilities of a given phone by looking at the capabilities of its family, unless a certain feature is specifically different for that phone. To further clarify, here is a concrete example. Nokia shipped several subversion of the 7110 model. Some of those did not support WML tables. Some did. The WURFL models this knowledge elegantly thanks to the fall_back mechanism. First, the generic family specifies a capability called "table_support": <device fall_back="root" id="generic" user_agent=""> <group id="ui"> : <capability name="table_support" value="true" /> </group> you can read this as "Generic WAP devices support WML tables" As a WURFL default, Nokia phones support tables because of fall_back on generic. This is modelled here: <device user_agent="Nokia" fall_back="generic" id="nokia_generic"> <group id="ui"> <capability name="break_list_of_links_with_br_element_recommended" value="false" /> </group> </device> When it comes to table support, the line above implies that for a generic Nokia device the same value as generic should be used. Two interesting device families follow: <device user_agent="Nokia7110/1.0 (04" fall_back="nokia_generic" id="nokia_7110_ver1"> : <group id="ui"> : <capability name="table_support" value="false" /> </group> </device> <device user_agent="Nokia7110/1.0 (04.67)" fall_back="nokia_7110_ver1" id="nokia_7110_ver1_sub467" /> <device user_agent="Nokia7110/1.0 (04.69)" fall_back="nokia_7110_ver1" id="nokia_7110_ver1_sub469" /> : <device user_agent="Nokia7110/1.0 (04.94)" fall_back="nokia_7110_ver1" id="nokia_7110_ver1_sub494" /> <!-- 7110 new-age --> <device user_agent="Nokia7110/1.0 (05" fall_back="nokia_7110_ver1" id="nokia_7110_ver2"> <group id="ui"> <capability name="table_support" value="true" /> </group> </device> <device user_agent="Nokia7110/1.0 (05.00)" fall_back="nokia_7110_ver2" id="nokia_7110_ver1_sub500" /> <device user_agent="Nokia7110/1.0 (05.01)" fall_back="nokia_7110_ver2" id="nokia_7110_ver1_sub501" /> When it comes to table support, this can be read as "there is a family of phones subset of the 7110 for which tables are not supported and there is a family for which they are supported". All known 7110 devices are contained in the list, but each one falls in one or the other subfamilies. This lets you model if a given device supports tables or not. What about UAProf?  >>

Enter your search terms Submit search form