A contribution to this discussion:
- As a general option, our choice for string<->integer
relations is close to solution 4
(Disallow dynamic tag assignments, and define all tags in a tag
file to be read by all programs at startup).
This is a result of our choice to administrate as much as
possible with Oracle and to provide applications with read-only
"data-bases" for configuration data.
This is not very flexible but it garanties the equivalence
of string vs integers and as a result, we only use integers in
Remote Procedure Calls.
- Solution 5 can support this option as well (to have
symbols defined outside of applications) and it adds some
flexibility, so its sounds very good.
It has additionnal costs, compared with solution 4,
but, as a result of the functionnality described
(server's specific mapping), it could also allow to have servers
running in an environment where the string<->integer data
has not been made available.
A CERN-PS example about string<->data conversions:
The technical solution we are using for such string<->integer
data on workstations is based on "dbm" files over NFS.
While the system used similar solutions for distributing
"passwd", "host", etc. we had no problem with availability.
On front-ends computers, we don't use "dbm" and all the necessary
symbols are produced in C files and compiled with the front-end's
image.
All these symbols are produced from Oracle tables.
We are happy with this (since 92). However, we encountered cases
where it is necessary that the workstations transmit to the
front-end some additionnal symbols as part of a transaction.
These cases comes from the facts that (1) data read from files
are usually "cached" in memory, updating it concretly implies
re-starting taks, which is not convenient for front-ends,
(2) some application-specific symbols (like tags) requires
more flexibility than the front-end's configuration
data (like device name).
Summary:
- Solution 4 is OK, however every
hosts need to access the same data.
There can be different distribution mechanism,
provided the data source is unique.
- Solution 5 is more sophisticated,
while it can also support remote hosts which
don't have access to symbol definitions
and it provides more flexibility for critical
systems.
I hope I understood the question...
--
Franck Di Maio, mail: franck.di_maio@cern.ch
PS Division, CERN, tel: (41) 22 767 2592
CH-1211 Geneva 23. fax: (41) 22 767 9145