The QNX PPS service uses an object-based system; that is, a system with objects whose properties a publisher can modify. Clients that subscribe to an object receive updates when that object changes — when the publisher has modified it.
Thus, users can:
For more information about publishing and subscribing, see the chapters Publishing and Subscribing.
|The QNX PPS design is in many ways similar to many process control systems where the objects are control values updated by hardware or software. Subscribers can be alarm handling code, displays, and so on.|
PPS objects are implemented as files in a special PPS filesystem. By default, PPS objects appear under /pps. These objects contain attributes.
There is never more than one instance of a PPS object, so persistence is a natural property that can be applied to PPS objects.
|In order to avoid possible confusion or conflict in the event that applications from different organizations are integrated to use the same PPS filesystem, we recommend that you use your organization's web domain name to create your directory inside the PPS directory. Thus, QNX, whose internet web domain name is “qnx.com” should use /pps/qnx, while an organization with the domain name “example.net” should use /pps/example.|
PPS holds its objects in memory, and therefore these objects are small:
The number of PPS directories and objects is limited only by available memory. The depth of PPS directories is limited by the fact that the full pathnames of objects are stored in the persistent directory as files; the size of these pathnames is limited by the maximum filename size supported by the persistent filesystem used.
PPS directories can include special objects that you can open to facilitate subscription behavior. The table below lists these special objects:
|.all||Open to receive notification of changes to any object in this directory.|
|.notify||Open a notification file descriptor in the PPS filesystem root.|
|.server||When opened by client, a unique “instance” or “channel” of the object is created, which only that client can see.|
For more information about these objects, see “Subscribing to multiple objects” the chapter Subscribing.
In PPS, the first line of a file names the object. This line is prefixed with an “@” character to identify it as the object name. The lines that follow define the object's attributes. These lines have no special prefix.
For example, in the PPS filesystem under the directory /pps/media/, the PPS object “PlayCurrent” contains the metadata for the currently playing song in a multimedia application. Let us assume that the metadata has the following schema:
@PlayCurrent author::[Presentation text for track author] album::[Presentation text for album name] title::[Presentation text for track title] duration::[Track duration, floating point number of seconds] time::[Track position, floating point number of seconds]
An open() call followed by a read() call on this file would return the name of the object (the filename, with an “@” prefix), followed by the object's attributes with their values:
@PlayCurrent author::Beatles album::Abbey Road title::Come Together duration::3.45 time::1.24
In listings of the PPS filesystem, PPS objects have no special identifiers. That is, they will appear just like any other file in a listing. Thus, the PPS object “PlayCurrent” used in the example above will appear in a listing as simply /pps/media/PlayCurrent.
When PPS creates, deletes or truncates an object (a file or a directory), it places a notification string into the queue of any subscriber or publisher that has open either that object or the .all special object for the directory with the modified object.
The syntax for this notification string is a special character prefix, followed by the object identifier “@”, then the object name, as follows:
|+||+@objectname||PPS created the object. To know if a created object is a file or a directory, call stat() or fstat().|
|-||-@objectname||PPS deleted the object.|
|#||#@objectname||PPS truncated the object.|
|*||*@objectname||The object has lost a critical publisher. All non-persistent attributes have been deleted. For more information, see the chapter Pathname Open Options.|
A deleted object is no longer visible in the filesystem (POSIX behavior), and only those processes with open file descriptors can continue accessing it. Therefore, typical behavior for an application receiving notification that an object has been deleted would be to close the file.
PPS objects have user-defined attributes. Attributes are listed in a PPS object after the object name.
Attribute names may be composed of alpha-numeric characters, underscores and periods, but must begin with a letter or underscore. Attribute lines in a PPS object are of the form attrname:encoding:value\n, where attrname is the attribute name, and encoding defines the encoding type for value. The end of the attribute name and the end of the encoding are marked by colons (“:”). Subsequent colons are ignored.
PPS does not interpret the encoding; it simply passes the encoding through from publisher to subscriber. Thus, publishers and subscribers are free to define their own encodings to meet their needs. The table below describes possible encoding types:
|::||Simple text terminated by a linefeed|
|:c:||C language escape sequences, such as “\t” and “\n”. Note that “\n” or “\t” in this encoding is a “\” character followed by an “n” or “t”; in a C string this would be “\\n\\t”|
|:b64:||Base 64 encoding.|
An attribute's value can be any sequence of characters, except: