From OpenHome

(Difference between revisions)
Jump to: navigation, search
(Topology1)
(Topology2)
Line 31: Line 31:
==Topology2 Classes==
==Topology2 Classes==
===Topology2===
===Topology2===
 +
Topology2 watches Topology1::Products and updates Topology2Group list whenever a ProxyProduct is added/removed from Topology1::Products
 +
===Topology2Source===
===Topology2Source===
===Topology2Group===
===Topology2Group===

Revision as of 10:41, 17 February 2015

ohTopology


Contents

Overview

ohTopologyC is a software stack which provides a means of controlling devices, on a local network, via their UPnP service actions. Devices are grouped them based on their Room names and presented as a tree structure based on their interconnectivity. It consists of a number of distinct layers. Each layer focuses on exposing specific properties and actions that are intended to be utilised by the layers above. Clients of ohTopologyC need only interface directly with the highest layer of the stack to gain access to the properties and actions exposed by the lower layers.


Watchable System

Overview

Actions exposed by a layer can be called directly, but property values can only be monitored through a callback notification system (observer pattern). Properties are exposed as "watchable" values that may be monitored by "watcher" clients. When a (watchable) property changes, all of its watchers are automatically notified of the change and the property's new value. Watchers can be added and removed at any time. The IWatchable interface is used to expose single value properties and the IWatchableUnordered/IWatchableOrdered interfaces are used for multivalue property lists. Property client objects must conform to the appropriate Iwatchable/IWatchableUnordered/IWatchableOrdered interface for the property that they wish to observe.

Watchable Thread

Although ohTopologyC is designed to run on multithreaded platforms, actions are executed in a single thread through the use of a thread scheduler class, WatchableThread. Enforcing single threaded execution removes the burden of having to manage thread safety, simplifies debugging and reduces the risk of deadlock. The WatchableThread class provides three methods; Execute, Schedule and Assert.

Schedule Method (asynchronous callback)

Schedule provides a mechanism for asynchronous callback. The specified callback is placed in a queue (FIFO) to be run on the watchable thread, in turn, at some point in the future. Schedule takes a functor, for the callback method, and a generic void* argument to be passed to the callback.

Execute Method (synchronous callback)

Execute provides a mechanism for synchronous callback. If called from the watchable thread it executes the callback immediately. Otherwise it schedules the callback, for execution on the watchable thread. In either case, it blocks until the callback has completed. Execute takes a functor for the callback method and a generic void* argument to be passed to the callback.

Assert Method

Assert provides a way of checking (using ASSERT) if the current thread is the watchable thread.

Topology1 Classes

Topology1

Topology1 collects a list of devices (with Product Service) from Network and adds itself as a watcher of this list. When a device is added to the list a ProxyProduct (proxy to device's Product service) is created and added to the Topology1 Products list. This list is exposed, for consumption by Topology2, as an IWatchableUnordered.

ProxyProduct

Topology2 Classes

Topology2

Topology2 watches Topology1::Products and updates Topology2Group list whenever a ProxyProduct is added/removed from Topology1::Products

Topology2Source

Topology2Group

Topology3 Classes

Topology3

Topology3Group

Topology4 Classes

Topology4

Topology4Room

Topology4GroupWatcher

Topology5 Classes

Topology5

Topology5Room

Topology5Group

Topology5Source

Topology5GroupWatcher