| 4 |
|
Present: ajm4, tdb1 |
| 5 |
|
Absent: none |
| 6 |
|
|
| 7 |
– |
[tdb1: Documented by ajm4, comments added by tdb1.] |
| 8 |
– |
|
| 7 |
|
This meeting was between ajm4 and tdb1 to discuss and |
| 8 |
|
possibly implement parts of the CORE and FilterManager |
| 9 |
|
elements of the system. |
| 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 |
