Publish and Subscribe

Overview

The Qt Value Space unifies various sources of hierarchical data into a single consistent model. Conceptually the Value Space is a hierarchical tree of which each node or leaf can optionally contain a QVariant value. A serialized version of a simple example Value Space might look like this.

    /Device/Buttons = 3
    /Device/Buttons/1/Name = Menu
    /Device/Buttons/1/Usable = true
    /Device/Buttons/2/Name = Select
    /Device/Buttons/2/Usable = false
    /Device/Buttons/3/Name = Back
    /Device/Buttons/3/Usable = true

Existing values within the Value Space are accessed through the QValueSpaceSubscriber class. This class provides a means to read values, receive change notifications for a given path and navigate through the Value Space.

New values are added to the Value Space via the QValueSpacePublisher class. This class allows applications to publish values and receive interest notifications when applications connect to a path. Interest notifications can be used to refrain from updating values in the Value Space when there are no interested parties.

Nodes in the Value Space can be thought of as representing schema objects. Obviously this is a conceptual differentiation and not a physical one, as internally the Value Space is treated as one large tree. By applying structured schema to the space "explore-ability" is increased. For example, the /Device/Buttons schema can be defined as containing a value representing the number of mappable buttons on a device, and a sub-item for each adhering to the MappableButton schema. The MappableButton schema itself may be defined as containing two attributes Name and Usable. Change notification is modeled in this fashion also. Were the /Device/Buttons/1/Name item to change, the /Device/Buttons/1 item would also be marked as changed, and so on up the tree. This allows, for example, subscribers to /Device/Buttons to be notified when anything "button" related changes.

Internally, the Value Space consists of an arbitrary number of data source trees, or layers, which are stacked on top of each other to form the final unified view. If a "higher" layer contains an item, it shadows the value of items in the layers below it. Consider the Value Space item /Device/Buttons. If two layers contained this item, the value in the layer with the higher layer order would shadow that with the lower layer order. However, if only the layer with the lower order contained this item, it would be visible through the QValueSpaceSubscriber class, even if the higher order layer contained sub-items such as /Device/Buttons/1. That is, layer shadowing occurs by value not by path.

Layer order is fixed and is defined in the layer implementation.

The following Value Space layers are available:

The Value Space has support for both client/server and peer-to-peer layer architectures. If a layer that uses a client/server architecture is used and a server process is not provided by the underlying system it will be necessary to start one. This can be done by calling QValueSpace::initValueSpaceServer() prior to any other use of the Value Space.

    <?xml version="1.0" encoding="UTF-8"?>
    <repository target="RProperty" version="" uidName="KPSUidHWRMPowerState" uidValue="0x10205041">
        <key ref="/resources/battery/level" int="0x00000001"/>
        <key ref="/resources/battery/status" int="0x00000002"/>
        <key ref="/resources/charging/status" int="0x00000003"/>
    </repository>

    <?xml version="1.0" encoding="UTF-8"?>
    <repository target="CRepository" version="" uidName="KCRUidProfileEngine" uidValue="0x101f8798">
        <key ref="/profile/id" int="0x7e000001"/>
    </repository>

    symbian {
        crml.sources = resources.qcrml profile.qcrml
        crml.path = c:/resource/qt/crml
        DEPLOYMENT += crml
    }