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.
Abstract
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:
- A Orange Labs extension for Mozilla Firefox 2
browser.
- A Nokia implementation for Mozilla minimo
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.
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:
- All DCCI properties in the test property tree should have
NamespaceURI =
"http://www.w3c.org/DCCI/Testing".
- The GPS property in the hierarchy is a property that
changes value periodically raising
the
DCCI-prop-change event.
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.
Implementations
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.
Implementation
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.
Nokia
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.
Implementation
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.
Testing
Test results for each of the implementations can be found on the
Tests and Results page.