WURFL stands for Wireless Universal Resource FiLe. It is part of a FOSS (which stands for Free and Open Source Software) community effort focused on the problem of presenting content on the wide variety of wireless devices. The WURFL itself is an XML configuration file which contains information about device capabilities and features for a variety of mobile devices. Device information is contributed by developers around the world and the WURFL is updated frequently reflecting new wireless devices coming on the market. Luca Passani is the driving force behind WURFL.
History: At the end of 1999 the first WAP phone was launched in Europe, followed by many others in the following months. By 2001 it became clear that WAP devices exhibited significant differences in the way they handled WAP content. The implication of this was that mobile developers found it difficult to support the increasing numbers of devices; the cost of application development, cost of testing and the cost of the very devices made WAP development expensive as compared to web development. Eventually, some developers realized that they could leverage the open-source model for their efforts. Luca Passani and Andrea Trasatti joined forces to build a community around a shared repository of device capability information, which they named WURFL. Over the years the project has gained followers and supporters from different geographical regions and with different backgrounds. The first basic API was in Perl. Java and PHP libraries appeared shortly afterward, soon followed by a better .NET Framework, Perl version, Ruby, and, more recently, Python, XSLT and C++.
The Problem (device fragmentation): The desktop web-channel, which is primarily divided up between a handful of browsers, relies on HTML as its markup, and content written as HTML can be expected to be visible to most users of a web-based channel via one of the standard browsers (Internet Explorer, Mozilla Firefox, Safari, Opera, and so on). Software updates for desktop browsers are frequently made and widely distributed. Unlike the desktop web-channel, there is a tremendous amount of fragmentation in the mobile device-channel. Mark-up can be WML, HTML, HDML, XHTML Mobile Profile, etc. In addition, unlike a standard desktop web-channel, a wireless-device channel will vary on screen size, ability to support client side scripting, ability to support various image formats, and even colour. Because the mark-up is generally sent directly to the phone, there is no opportunity for a central server to "fix" or adapt to browser limitations or defects. Software updates for mobile browsers are rare.
Solution Approaches: There have been several approaches to this problem, including developing very primitive content and hoping it works on a variety of devices, limiting support to a small subset of devices or bypassing the browser solution altogether and developing a Java ME or BREW client application. WURFL solves this by allowing development of content pages using abstractions of page elements (buttons, links and textboxes for example). At run time, these are converted to the appropriate, specific mark-up types for each device. In addition, the developer can specify other content decisions be made at runtime based on device specific capabilities and features (which are all in the WURFL).
High-bandwidth Digital Content Protection (HDCP) is a specification developed by Intel Corporation to protect digital entertainment content across the DVI/HDMI interface. The HDCP specification provides a robust, cost-effective and transparent method for transmitting and receiving digital entertainment content to DVI/HDMI-compliant digital displays.
HDCP is designed for protecting audiovisual content over certain high-bandwidth interfaces. These interfaces include:
- DVI (Digital Visual Interface)
- HDMI (High Definition Multimedia Interface)
- UDI (Unified Display Interface)
- GVIF (Giga-bit Video Interface)
- DLI (Digital Light Interface)
- MHL (Mobile High-Definition Link)
In an HDCP system, two or more HDCP devices are interconnected through an HDCP-protected interface. The audiovisual content protected by HDCP flows from the Upstream Content Control Function into the HDCP system at the most upstream HDCP Transmitter. From there, the HDCP content, encrypted by the HDCP system, flows through a tree-shaped topology of HDCP receivers over HDCP-protected interfaces.
The HDCP content protection mechanism includes three elements: 1) Authentication of HDCP receivers to their immediate upstream connection (to an HDCP transmitter). The authentication protocol is the mechanism through which the HDCP transmitter verifies that a given HDCP Receiver is licensed to receive HDCP. 2) Revocation of HDCP receivers that are determined by the DCP to be invalid. 3) HDCP encryption of audiovisual content over the HDCP-protected interfaces between HDCP transmitters and their downstream HDCP receivers.
HDCP receivers may render the HDCP content in audio and visual form for human consumption. HDCP receivers may be HDCP repeaters that serve as downstream HDCP transmitters emitting the HDCP content further downstream to one or more additional HDCP receivers.