accessing configuration data

*	overview

Conceptually, all configuration data is bound to a database.
Databases are organized in SCHEMAS,
with one schema representing local databases
and other schemas corresponding to remote server stubs.
While many configuration options may be treated likewise
for local and remote schemas, some options, such as file paths,
are meaningful only within the local schema
and should not be distributed by servers.


*	schema and database access

Schemas are accessed by either names or numbers (one byte),
the local schema has empty name and number 0.
A remote schema's name may be an URL like "host" or "host:port"
(possibly one day even with protocol like "z3950://...")
or a symbolic name, typically referring to some local
configuration source for host and other parameters.

Within each schema, databases are accessed by either
simple names like "cds" or numbers (two bytes).
A main entry with empty name and number 0 holds options which
are global to a schema and/or serve as defaults for databases.


In addition to the configuration data,
each schema entry may contain data related to the actual implementation,
e.g. file id's for a local database or sockets in a remote schema's
main entry.


*	configuration parameters

A database's configuration can for the most part be considered one record
with nested subrecords.
For efficient access, however, several logical subrecords may
be available as records on their own and/or in a parsed representation.

A configuration entry includes
-	general parameters record
	These include traditional standard system and database parameters,
	encoding names, named texts to be interpreted as "printformats" (PFT)
	and so on. This record's metadata is
>	Builtin
-	a parsed version of the FDT
-	a parsed version of the FST
-	optional character tables
	These are corresponding to the ISISAC.TAB,
>	http://www.cindoc.csic.es/isis/21-5.htm	ISISUC.TAB, SRT-files
	and recoding tables as of
>	Syspar
	106, 107.
-	optional named views
	The sort of "printformat" acting as database views.
-	stopword list (STW)

Several of these are used only for indexing and thus
are usually not needed in a remote database description.

Some environments may use additional data like work sheets (FMT).


*	implementation notes

-	mapping of names to numbers is relative to each process.
	between processes, only names may be exchanged.
-	most ressources are accessed using defaulting,
	i.e. if a parameter is not found in the entry of a given database,
	it is searched for in the schema's main entry.
-	in the traditional (WinISIS) implementation of local schema
	configuration data, named PFTs, FMTs and other are looked up as files,
	which are not actually relative to a database, but to either
	the schema's standard directory or a tool directory as of dbname.par 10.
	While the sharing of such ressources in the standard directory
	corresponds to placing them in a schema's main entry,
	other --possibly shared-- tool directories will (some day)
	be implemented by additional database entries,
	which may be referred to by other databases.


*	synchronization

All configuration ressources can be modified only
by the default session.
Other sessions can assume them to be immutable
for the lifetime of one request.

If the default session wants to change a configuration,
the database has to be remounted in single user mode,
inaccessible to other sessions.
This might involve some waiting for other sessions
to finish their current request.


To support this, each database entry has a mount status and a
count of sessions using it (not counting the default session).

For details see the paper on
>	Concurrency
.


---
	$Id: Config.txt,v 1.3 2003/02/13 16:58:45 kripke Exp $