The Config Tree API is used by apps to read and write their specific configurations. Each app is given an isolated tree. The system utilities store their configuration in the root
tree.
Paths in the tree look like traditional Unix style paths like this:
The path root is the root of the tree where the app has been given access. If the app has permission to access another tree, the path can also include the name of the other tree, followed by a colon.
In this case, a value named value
is read from the tree named secondTree
The tree is broken down into stems and leaves.
A stem is a node that has at least one child node. A leaf has no children, but can hold a value.
The config tree supports string, signed integer, boolean, floating point, and empty values. It's recommended to store anything more complex using stems and leaves, which enhances readablity and debugging. It also sidesteps nasty cross platform alignment issues.
The config tree uses simple transactions to work with its data. Both read and write transactions are supported. Use read transactions to ensure you can atomically read multiple values from your configuration while keeping consistency with third parties trying to write data.
To prevent a single client from locking out other clients, read and write transactions have their own configurable timeout.
During a write transaction, both reading and writing are allowed. If you write a value during a transaction and read from that value again, you will get the same value you wrote. Third party clients will continue to see the old value. It's not until you commit your transaction that third parties will begin to see your updated value.
During read transactions, writes are not permitted and are thrown away.
Transactions are started by creating an iterator. Either a read or write iterator can be created. To end the transaction, you can delete the iterator, cancelling the transaction. Or,for write transactions, you can commit the iterator.
You can have multiple read transactions against the tree. They won't block other transactions from being creating. A read transaction won't block creating a write transaction either. A read transaction only blocks a write transaction from being comitted to the tree.
A write transaction in progress will also block creating another write transaction. If a write transaction is in progress when the request for another write transaction comes in, the secondary request will be blocked. This secondary request will remain blocked until the first transaction has been comitted or has timed out. The transaction timeout default is 30 seconds. You can extend the timeout by setting a value (in seconds) in configTree/transactionTimeout
.
This code sample shows how to iterate a specified node and print its contents:
This code sample uses a write transaction to update a target's IP address so the data is written atomically.
This is a code sample of a read transaction.
It's possible to ignore iterators and transactions entirely (e.g., if all you need to do is read or write some simple values in the tree).
The non-transactional reads and writes work almost identically to the transactional versions. They just don't explictly take an iterator object. The "quick" functions internally use an implicit transaction. This implicit transaction wraps one get or set, and does not protect your code from other activity in the system.
Because these functions don't take an explicit transaction, they can't work with relative paths. If a relative path is given, the path will be considered relative to the tree's root.
Translating this to a "quick" (non-transactional) example looks like this:
Copyright (C) Sierra Wireless Inc. Use of this work is subject to license.