From 76f5b4db8be97194a9ba0c44081796304da06347 Mon Sep 17 00:00:00 2001 From: Sebastian Hammer Date: Sun, 25 Mar 2007 16:06:35 +0000 Subject: [PATCH] This file -- not valid XML -- contains illustrative examples of the configuration file format I have in mind. It is basically a mechanism to allow you to set multiple name-value pairs for targets -- possibly user specific. The various forms are intended to support various activities -- like setting system-wide defaults, overriding settings for one user or target, setting up values for a specific target, etc. There's even a verbose form that would lend itself well to dumping values out of a relational database... indeed, it's possible to imagine an extension that would allow pazpar2 to access settings from an RDBMS, although this is not planned at present. --- etc/example-settings | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 etc/example-settings diff --git a/etc/example-settings b/etc/example-settings new file mode 100644 index 0000000..97949da --- /dev/null +++ b/etc/example-settings @@ -0,0 +1,104 @@ + +Each of the following examples is an example target settings file. On startup, +pazpar2 will read any number of these files recursively from a directory hierarchy. +Explanations for the examples below. + +The following file explicitly sets name=value for a whole bunch of targets for a +bunch of users.. I don't imagine this format will be used much for human +entry, but it might be used to export settings from a relational database.. it is +also there as one extreme form of a generic format. + +If user is omitted, the setting applies to any user. For target, there are two wildcard +forms: * matches any target not otherwise matched, and xx/* matches any database on a given +host. A setting for an explicit host/db always overrides a wildcard setting. + + + + + + + +More useful, you can group a number of settings about a target into one file like this. +This comes closer to the conventional target setting files we're used to. + + + + + + + +This file sets a number of name=value pairs for a list of targets. A typical example might +be to associate all these targets with a specific category or type, or to otherwise make +them part of a set -- like 'all full-text', 'all free-access', etc. + + + + + + + + +Here's the shortest possible file.. it sets one name=value for one target + + + +This sets different values for a given named setting (attribute) for one target. + + + + + + + +This sets different values for one attribute for different targets + + + xx + xx + + + + + +This sets one or more named values for a set of targets. + + + xx + xx + xx + + + + +This is a more concrete example.. it allows specific users access to a given target. + + + + + + + +While this default setting disallows access to anything for everybody not otherwise +permitted... + +// Whitelist default -- disallow all access + + +.. except these 'free' targets which are open to anyone. + +// Except these ones + + + + + + +The setting below sets a default record normalization stylesheet. Yes, values can be simple +strings, or they can be XML trees. + + + + + + + -- 1.7.10.4