+++ /dev/null
-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 $
projects / webpac / blobdiff