1 |
dpavlin |
237 |
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 $ |