Registry Configuration
OVERVIEW
The JNIOR Automation Network Operating System (JANOS) and its applications
can be configured to suit your needs. Configuration involves choices, and
those settings may be stored in a variety of ways. JANOS relies on its
Registry system for all operating system configuration. The Registry can
also be easily used by applications and web pages for the storage of custom
configuration settings. The Registry may also be used to store and share
data dynamically.
The JANOS Registry is non-volatile. Its content remains in place even when
power is removed. Information is stored as a set of
name-value pairs. Each
entry is referenced by a unique
Registry Key or name. Each entry contains
information formatted as a character string representing its value. The
content is available to JANOS directly, to external applications and web
pages through protocols, and to local application programs through the
JanosClasses.jar runtime library. Sections of the Registry may be globally
shared amongst peer JNIORs on the local subnet.
JANOS maintains a backup copy of the Registry in the
/flash/jnior.ini file.
When content in the Registry is changed this INI file will later be updated
to reflect the changes. This backup file is automatically generated and should
not be overwritten or modified. JANOS performs this
backup every several
minutes as needed. The
/flash/jnior.ini file may be read and saved as a
representation of Registry content. This INI file will reflect changes only
after the backup occurs. The backup is automatically performed on reboot.
A copy of the
/flash/jnior.ini file may be edited and saved under a
different filename. This then may be ingested using the REG -I command as
means a performing bulk configuration.
All actions are logged to the
jniorsys.log file providing an audit trail
for configuration management.
ENTRY NAMES
Each entry in the Registry consists of a
name-value pair. Each name is
a unique (case-independent) string. These are formatted much like a file
path although there are no real folders or directories. The forward slash '/'
is still used as a logical separator.
The first (or leftmost) portion of the name (that up to the first separator)
defines a Registry
section. Most entries are grouped logically by section.
For instance, I/O settings all reside in the
IO section, device settings
are located in the
Device section. The structure of the balance of the
name (or
key ) is somewhat arbitrary and defines the purpose of the entry.
While there are Registry sections known to the operating system, applications
often define their own for configuration and data. This becomes a convenient
way to store information avoiding the processing of files.
Registry sections whose name begins with the percent character '%' may be
globally shared between peer JNIORs on the local subnet (see
GROUPADD).
KEY NAMES
The rightmost portion of the Registry entry name (that after the last forward
slash) represents the
key. This should clearly describe the purpose of
the entries
value. Registry names, and therefore its keys, are
case-independent. It is recommended that upper and lower case be carefully
used for readability. The Registry will retain the key as it is originally
entered although access need not be precise in case.
Entries in the Registry are carefully backed up in the
/flash/jnior.ini
file. This is to insure that configuration decisions are permanently retained.
The Registry, however, can be used to store data that may be changing all of
the time. For example a temperature value. There is no real need to backup
that information as it likely is regenerated by an application frequently.
Dynamic data should be stored in a
dynamic key. Those are identified using
the dollar sign character '$' as a prefix. For instance:
Readings/$Temperature = 74.3
Here a Fahrenheit reading is stored dynamically. This is not retained in
the INI backup file. This avoids updating that backup file too often as the
more often it is overwritten, the more likely it may be damaged when power
is lost. We also need to be cognizant of the fact that Flash memory has a
limited lifetime usually specified in a maximum count of guaranteed writes.
Save frequently changing data in the Registry using a dynamic key.
Note that dynamic keys should be stored in a Registry section. Those keys
using the '$' prefix in the root (top) of the Regitry are reserved by the
system. Those are
system keys defining key device information.
GLOBAL SHARING
When two devices participate in a common application they often need to
share information. To achieve this, connections have to be made and protocols
used in the exchange. The JANOS Registry provides a built-in means by which
entire sections of entries may be globally available to other JNIORs on the
same local network. The information stored within can be instantly accessed
by peer JNIORs without individual interconnection.
In order to share the Registry globally you must do two things. First you
need to define a global section using a name starting with the percent sign '%'
character. Only sections named in this fashion may be shared. For example
if a JNIOR with the appropriate environmental sensor wishes to share it
might define the following.
%office/$Humidity = 41.88
%office/$Temperature = 75.99
An application would periodically read the sensor and write these keys. This
can be easily done using the
Tasker application freely supplied for the
JNIOR.
Second, you need to define the
sharing group using the GROUPADD command and
specifying the '%office' group name. While that command might be typically
used to specify groups of users, in JANOS it can also define sharing groups.
One or more sections of the Registry may be individually shared.
To access this data from another JNIOR, you need to also issue the same
GROUPADD command there for the same group name '%office'. If both JNIORs
are on the same local network, the above keys should be available on both
JNIORs. Use the REGISTRY (or REG) command to list them. In fact, the following
will display any shared keys.
bruce_dev2 /> reg -e %
%office/$Humidity = 41.88
%office/$Temperature = 75.99
bruce_dev2 />
OWNERSHIP
Normally all Registry keys are
owned by the built-in system 'root' account.
However, shared keys defined elsewhere and received through global sharing are
locally owned by another built-in account called 'shared'. You only have
READ access to these keys owned by 'shared' (even if you are the administrator).
Only the originator may alter (or delete) the keys it creates. The -O option
with the REGISTRY command may be used to view ownership.
DATA EXCHANGE
Protocols are used (like the JMP Protocol) through a
connection to pass
information from one device to another. The global Registry sharing is
connectionless. In fact, it uses what amounts to a
sub-space channel to
get the job done regardless of IP address configuration or login credentials.
Since shared keys may be created by any participant in a shared group, a form
of handshake might be possible using this "channel". For instance, one JNIOR
can create a shared key (using a dynamic key please) carrying some data. The
consumer of that data recognizes its arrival and creates a key called 'ACK'
or something along those lines. The originator of the data recognizes the
arrival of the 'ACK' and confidently removes the data key. The consumer likewise
in seeing the data disappear removes the acknowledgement. This achieves a
confirmed data exchange.
Things of this nature are dependent on your skill in writing application
programs for the JNIOR.
SEE ALSO
HELP Topics:
REG
[/flash/manpages/registry.hlp:4]