[lcdproc] Hashes and config file. ;-) (and dynamic load)

Matt madmatt@bits.bris.ac.uk
Tue, 27 Mar 2001 17:34:20 +0100 (BST)


Andre Breiler mentioned the following:

| Yes it's a plain text file and only writeable with a texteditor by the
| admin :)
| So a driver can't replace the setting for the client ...

The config file should only be createable by the admin. LCDproc reads it,
and does nothing more with it.

| > The config file has been read completely anyway, so why not keep the 
| > data ? And it's easy to add a write function later...
| 
| It's a waste of memory i think.
| What would you do with a write function ? (sorry I can't see any use).

The only reason I can see for it, is if we implemented something like
Samba's swat utility. A little OTT methinks.

| > sections with 10 keys, using a hashtable would be like using a tractor 
| > in your backyard :)
| 
| Hmmm, but if you query the config database often then the tractor would be
| useful ?

A hash will be better if you repeatedly request a specific parameter, that
for the sake of arguments, would be near the end of a linked
list/table. You would remove the "is it this? no. next. is it
this? no..." syndrome.

| > kill -HUP pid
| > Then it should reread config files, and tell drivers that the config 
| > has changed. Then they should decide what to do. Is that OK?
| 
| Yes it's ok. But what with removed/added drivers ?

Sending a SIGHUP should perform a full reset on the server side. A re-read
of the config file, remove and add drivers where necessary, maybe just
reconfig them in some cases. If we can do that without disturbing any
clients, that would be ideal.

Basically, the equivalent of stopping and starting it without losing the
client connections.

my 2p

Matt



-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net