| 22 |
|
[tdb1: this will also solve security issues with |
| 23 |
|
unauthorised third parties changing settings.] |
| 24 |
|
|
| 25 |
+ |
A standard has almost be devised for filenames of |
| 26 |
+ |
configuration files. As it stands all hostname properties |
| 27 |
+ |
will be get in a file with the following name; |
| 28 |
+ |
|
| 29 |
+ |
hostname.domain.properties |
| 30 |
+ |
|
| 31 |
+ |
nb. This will always be *lower case*. This is important as |
| 32 |
+ |
some hosts (eg. stuE...) have mixed case, so having all |
| 33 |
+ |
lower case saves confusion. |
| 34 |
+ |
|
| 35 |
+ |
However, any other config files (such as the filterManager) |
| 36 |
+ |
can have any name in any case. The file itself will be of |
| 37 |
+ |
the name format; |
| 38 |
+ |
|
| 39 |
+ |
name.properties |
| 40 |
+ |
|
| 41 |
+ |
So in the case of the filterManager this would be |
| 42 |
+ |
"filterManager.properties". |
| 43 |
+ |
|
| 44 |
+ |
A standard should be defined here for concistency. |
| 45 |
|
|
| 46 |
|
Next point was whether or not we would support elements |
| 47 |
|
being able to be updated without restarting them, ie. a host |
