1 |
accessing configuration data |
2 |
|
3 |
* overview |
4 |
|
5 |
Conceptually, all configuration data is bound to a database. |
6 |
Databases are organized in SCHEMAS, |
7 |
with one schema representing local databases |
8 |
and other schemas corresponding to remote server stubs. |
9 |
While many configuration options may be treated likewise |
10 |
for local and remote schemas, some options, such as file paths, |
11 |
are meaningful only within the local schema |
12 |
and should not be distributed by servers. |
13 |
|
14 |
|
15 |
* schema and database access |
16 |
|
17 |
Schemas are accessed by either names or numbers (one byte), |
18 |
the local schema has empty name and number 0. |
19 |
A remote schema's name may be an URL like "host" or "host:port" |
20 |
(possibly one day even with protocol like "z3950://...") |
21 |
or a symbolic name, typically referring to some local |
22 |
configuration source for host and other parameters. |
23 |
|
24 |
Within each schema, databases are accessed by either |
25 |
simple names like "cds" or numbers (two bytes). |
26 |
A main entry with empty name and number 0 holds options which |
27 |
are global to a schema and/or serve as defaults for databases. |
28 |
|
29 |
|
30 |
In addition to the configuration data, |
31 |
each schema entry may contain data related to the actual implementation, |
32 |
e.g. file id's for a local database or sockets in a remote schema's |
33 |
main entry. |
34 |
|
35 |
|
36 |
* configuration parameters |
37 |
|
38 |
A database's configuration can for the most part be considered one record |
39 |
with nested subrecords. |
40 |
For efficient access, however, several logical subrecords may |
41 |
be available as records on their own and/or in a parsed representation. |
42 |
|
43 |
A configuration entry includes |
44 |
- general parameters record |
45 |
These include traditional standard system and database parameters, |
46 |
encoding names, named texts to be interpreted as "printformats" (PFT) |
47 |
and so on. This record's metadata is |
48 |
> Builtin |
49 |
- a parsed version of the FDT |
50 |
- a parsed version of the FST |
51 |
- optional character tables |
52 |
These are corresponding to the ISISAC.TAB, |
53 |
> http://www.cindoc.csic.es/isis/21-5.htm ISISUC.TAB, SRT-files |
54 |
and recoding tables as of |
55 |
> Syspar |
56 |
106, 107. |
57 |
- optional named views |
58 |
The sort of "printformat" acting as database views. |
59 |
- stopword list (STW) |
60 |
|
61 |
Several of these are used only for indexing and thus |
62 |
are usually not needed in a remote database description. |
63 |
|
64 |
Some environments may use additional data like work sheets (FMT). |
65 |
|
66 |
|
67 |
* implementation notes |
68 |
|
69 |
- mapping of names to numbers is relative to each process. |
70 |
between processes, only names may be exchanged. |
71 |
- most ressources are accessed using defaulting, |
72 |
i.e. if a parameter is not found in the entry of a given database, |
73 |
it is searched for in the schema's main entry. |
74 |
- in the traditional (WinISIS) implementation of local schema |
75 |
configuration data, named PFTs, FMTs and other are looked up as files, |
76 |
which are not actually relative to a database, but to either |
77 |
the schema's standard directory or a tool directory as of dbname.par 10. |
78 |
While the sharing of such ressources in the standard directory |
79 |
corresponds to placing them in a schema's main entry, |
80 |
other --possibly shared-- tool directories will (some day) |
81 |
be implemented by additional database entries, |
82 |
which may be referred to by other databases. |
83 |
|
84 |
|
85 |
* synchronization |
86 |
|
87 |
All configuration ressources can be modified only |
88 |
by the default session. |
89 |
Other sessions can assume them to be immutable |
90 |
for the lifetime of one request. |
91 |
|
92 |
If the default session wants to change a configuration, |
93 |
the database has to be remounted in single user mode, |
94 |
inaccessible to other sessions. |
95 |
This might involve some waiting for other sessions |
96 |
to finish their current request. |
97 |
|
98 |
|
99 |
To support this, each database entry has a mount status and a |
100 |
count of sessions using it (not counting the default session). |
101 |
|
102 |
For details see the paper on |
103 |
> Concurrency |
104 |
. |
105 |
|
106 |
|
107 |
--- |
108 |
$Id: Config.txt,v 1.3 2003/02/13 16:58:45 kripke Exp $ |