 |
|
    |
 |
|
 |
This article was written by Luca Passani, Openwave's Developer Support Engineer located in Italy.
Hello! Ciao! This is not the first time we have talked about WURFL (Wireless Universal Resource FiLe) on the Openwave Developer site, so you may wonder why we are starting with another introduction. The fact is the Openwave Developer Network (ODN) team recently looked at WURFL again and we thought so much had changed, that we wanted to bring everyone up to date. In 2004, we thought that WURFL was cool and now our attitude has changed. We now think that WURFL is really, really, really cool! Not only has the repository extended to contain over 5000 devices, but adoption has also conspicuously taken off. If you add to it the fact that WALL (Wireless Abstraction Library) delivers a truly universal mark-up, what you get is a ridiculously powerful tool at no cost. For this reason, we have decided to dedicate a lot of time to the WURFL and WALL projects in the months to come. We hope you share our excitement. Dr. Jekyll and Mr. Hyde: A Developer's Story There is something funny going on here. One of the WURFL authors also works for Openwave (as is a member of the ODN team). He also happens to be the person who is writing this article. Yep, it's me: Luca Passani. So before this gets too confusing, let me switch to the first person right away and provide some explanation. My job at Openwave, among other things, is focused on supporting wireless developers and helping with the content on our developer site. For a long time, I have also been a very active participant on wireless mailing lists - even before I joined Openwave. In particular, I actively participate on the WML Programming mailing list, which is where WURFL was born and bred. I realize, I have developed a split personality: I am a dedicated employee of an American corporation one minute, and I turn into your average "rage-against-the-machine" hacker one minute later. It's always me. Only the email address changes! Now, this situation could have happily continued for a long time if it wasn't for a fortunate event: WURFL and WALL have become wildly popular. WURFL has evolved from a utility adopted by a group of programmers to a flexible framework that many companies have bet their businesses on. Openwave's role in the WURFL project has been unusual. While there has never been a budget for creating a tool like WURFL as an Openwave product for developers, Openwave has always acknowledged the role it would play in the wireless programmers community. For this reason, Openwave has supported the project all the way. They have allowed me to use a conspicuous amount of time on WURFL during my "working" hours. It was an excellent decision. Originally, the ODN team was cautious about promoting WURFL. We did not want to give the impression of shamelessly promoting our own baby. But WURFL's popularity has wiped away those concerns and the Openwave Developer Network team can no longer afford not to give WURFL and WALL the attention it deserves. WURFL and WALL are mega-cool tools, which any self-respecting wireless developer should know about. And this puts me in an unusual position: I have to talk about my own creation as if it was someone else's. It feels kind of weird, but I have to confess that I am very proud of what we - including Andrea Trasatti and all the friends on the WML Programming mailing list - have achieved. So okay, that's enough of my true confessions. It's time to get technical. The rest of this article will talk about WURFL. This month's newsletter also contains a companion article about WALL. What is WURFL? WURFL is a repository of wireless device capabilities. The goal of the WURFL project is to describe the capabilities of common wireless devices around the planet and provide a simple API to programmatically query the capability repository. Figuring out device capabilities is a necessity for every non-vertical wireless application, be it WAP, MMS, J2ME or whatever. This need has been acknowledged by the industry and by standard bodies. Unfortunately the commercial tools to address the problem are typically prohibitively expensive for the great majority of developers and companies. This is not surprising if you consider that keeping a device database updated is a huge, tedious and expensive task. WURFL works around this problem by exploiting the community of developers around the world who decided to cooperate and exchange device information. Since the goal of WURFL is to be open and available on as many platforms as possible, XML was chosen as the format to capture device data. Nowadays, all programming languages and development platforms offer APIs to handle XML. The WURFL XML file structure (AKA DTD, or schema as some would call it) is very simple:
Figure 1: WURFL XML Structure The wurfl.xml is just a big list of devices and every device is a list of capabilities. At press time, wurfl.xml contained over 5000 devices. The number of capabilities represented in the WURFL is also copious: over 300. If you have never seen the WURFL file, you'll probably think that it is huge (5000x300). But that's not so. Consider this: no matter how revolutionary a new device is, chances are that 90% of the software running on that device is the same as that on an older device from the same manufacturer. This fact is exploited by WURFL when a new devices is inserted into a repository. The WURFL maintainer may not know anything about a device except the User-Agent string, yet this is enough to instruct the repository that the value of that device's capabilities should be inferred from another existing device. Not only does this turn up to be extremely useful to model different software subversions of the same device, but it also helps in keeping the size of the repository logarithmically compact as compared to the amount of data contained in it. This mechanism is called the fall_back. The following wurfl.xml snippet shows all of this in practice:
FIGURE 2: wurfl.xml fragment The <device> element models a device. As a minimum, it contains:
In addition to this data, a device may carry info about device features commonly referred to as capabilities and the actual_device_root="true" attribute to mark real devices As far as <group>s are concerned, groups are used solely to improve the readability of the WURFL XML database by humans (well, at least programmers). In other words, the WURFL capability namespace is flat and names should be unique also across groups. A device <capability> is way more interesting though. It contains information about a specific feature of a given device and all the devices "falling back" into it. Refer to the example in the Figure 2 to see what capabilities look like. You can find a complete list of capabilities with their description here: http://wurfl.sourceforge.net/help_doc.php. Of course, we will cover the most significant capabilities in future articles. At this point, you may wonder where you end up if you jump from one device to the other while following the fall_back chain. The answer is the 'generic' device. 'Generic' is the first device defined in WURFL and its role is to guarantee that queries for a capability value will always return a result. Just like the number zero in mathematics, 'generic' does not seem to count much, but in reality keeps the whole system on its feet. 'Generic' has each and every capability explicitly defined. Typically, the values are very conservative, since 'generic' represents that unmatched device and no assumptions can be made about a device you know nothing about. You're probably thinking, "This is all very nice, but how does one move from XML to action?" The WURFL data is only part of the value delivered by the WURFL project. The other relevant parts are the APIs available for different platforms. Most notably Java and PHP. These are by far the two most popular wireless development platforms. While Openwave data says that Java and PHP together cover over 70% of deployed systems, on the WURFL site you will also find APIs for Perl, DotNet, Ruby and Python. The Java API is the basis for the WALL Tag-Library explained in the other article. A more accurate tutorial of the Java API will be published next month.
A Code Snippet is Worth a Thousand Words This will produce: mot_t720_ver1_sub050841r Capability Matrix: query mms_vbxml capability for some Telit phone... false References:
|