Implementation Report for Delivery Context: Client Interfaces

Ubiquitous Web Applications Working Group

Status of this document

This document reports on implementation experiences and interoperability issues arising from the development of DCCI. The document formally supports the W3C Proposed Recommendation of DCCI that entered Candidate Recommendation status 21st December 2007.


This document contains individual interface tests of the test suite, implementation test results and implementation reports for the proposed recommendation of the DCCI specification. There are currently two implementations:

Implementation Assumptions

The data presented here is intended as proof of DCCI implementability. A compliant version of DCCI requires the implementation of the normative components of the recommendation. Table 1 is a list of individual tests along with the pass/fail status of the current implementations.

The DCCI test hierarchy.

Figure 1. The DCCI property hierarchy used for testing where * denotes a periodic property change.

The tests are broken down into small atomic unit tests using the property hierarchy in Figure 1. Testing requires a DCCI context, as a result the following assumptions are made:

There are many potential layout permuations that can be arbitarily deep and complex, therefore the property hierarchy illustrated in Figure 1. is non-normative and is used for test configuration purposes only. The examples illustrated in the specification show obvious data layouts, as well as layouts that demonstrate particular nuances of property access.


Orange Labs

This document describes the Orange Labs implementation of the Delivery Context Client Interfaces 1.0 Candidate Recommendation as an implementation for transition to Proposed Recommendation.


Orange Labs has created an implementation of DCCI as a browser extension for Mozilla Firefox 2.0 and as a statically linked component of Mozilla Minimo, both based upon the same source code.

The implementation defines several XPCOM IDL interfaces: nsIDCCIProperty matching IDCCIProperty nsIDCCIComponent matching IDCCIComponent nsIDCCIInitializable providing an internal interface by which properties can be initialized upon addition to the DCCI tree.

The nsDCCIProperty class implements the nsIDCCIProperty interface as well as provides implementations for the inherited methods from the DOM Element interface and DOM EventTarget interface. The nsDCCIProperty class maintains a static member representing the owner document of the DCCI property hierarchy. This nsDocument object is used in the creation of nsEvent instances used for firing appropriate events as changes occur in DCCI properties or to the DCCI property hierarchy. The nsDCCIComponent class inherits from nsDCCIProperty, in addition to implementing the additional GetVersion method.

In addition, an there is an nsDCCIFactory class implementing the HasFeature and GetFeature methods required in order to make access to the DCCIComponent available through document.getFeature(), in JavaScript.

DCCI properties themselves have been implemented as independent extensions for Firefox and statically linked in for Minimo. These specific property classes inherit from nsDCCIProperty overriding the approriate Get and Set methods (such as GetValue and SetValue.) In addition, these property classes take advantage of the Mozilla nsIObserver interface. This mechanism is used to notify these property classes upon DCCI initialization, such that they can then instantiate and initialized themselves appropriately and add the top-level of the sub-hierarchy they represent to the DCCI hierarchy itself.


This document provides the implementation report from Nokia Corporation for Delivery Context Client Interfaces (DCCI) 1.0 as candidate implementation towards transition of DCCI specification from Candidate Recommendation status to Proposed Recommendation status.


We have made two implementations of DCCI both of which differ only in way providers provision data to the DCCI model. These two implementations do not affect the way in which consumers (web applications) access contextual information through the DCCI model. Both these implementations have been made as extensions to Mozilla Microbrowser that is the standard browser for Nokia Linux Tablets. The OS thus is also Linux. We have not made an open implementation for Symbian. The implementations use GPS as the property to demonstrate adaptive web applications.

The first implementation of DCCI was demonstrated at the UWA meeting in March at South Korea,Seoul. The implementation is a browser extension which is installed in addition to the MicroB browser. Consequently, the implementation is entirely based on XPCOM. First, the interfaces were translated to XPIDL interfaces, from which the respective C++ headers were generated. The heart of the implementation is the nsDCCIProperty C++ class, which, in addition to the standardized interfaces, implements a few other interfaces for internal purposes aimed at provisioning of properties. The DCCIComponent interface is implemented by the nsDCCIComponent C++ class, which is a singleton and does not inherit from nsDCCIProperty. Instead, it owns a nsDCCIProperty instance representing the DCCI root property, to which the methods of the DCCIProperty interface are delegated.The value and the metadata interface of a DCCI property is implemented using the nsIWritableVariant Mozilla interface, which is similar to a union in C. To set a value,the respective nsIWritableVariant object needs to be obtained and modified using its various setter methods. In order to set a complex value ("struct"), an XPCOM component can be supplied. This means that an XPIDL interface and an XPCOM implementation object need to be created.

Our second implementation behaves exactly like the first with the difference that the provision of properties is not done statically to the DCCI model. The DCCI extension to the browser remains the same. This implementation supports sharing of resources between multiple networked devices. Resources can be shared by bringing devices close together so that they form an ad-hoc resource sharing network. Our implementation does this through Bluetooth discovery. The provisioning platform supports multiple applications simultaneously with the browser running the DCCI model as one application (the actual application would be the web page using the model though). We do this by providing a generic context model that will broadcast property messages over DBUS communication. The messages correspond to the events in DCCI specification. The browser provisioning interface converts these messages into appropriate actions and DCCI messages. For example, when a new property arrives, a "new property addition" signal is sent that will enable the DCCI provider to create a corresponding propery in the DCCI tree. The flow is optimized so that a subsciption to the property only occurs if there is a listener attached to the new property. The details of this implementation is outside the scope of this document and will be published in a seperate publication.


Test results for each of the implementations can be found on the Tests and Results page.

Ubiquitous Web Applications Working Group. Please send feeback to our public mailing list.

Last modified: $Date: 2008/08/25 19:48:23 $ by $Author: krosebl $