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

[William W. Ferrell]

--UTZ8bGhNySVQ9LYl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

--- andreb@rd.bbc.co.uk's mailer spewed these beefy chunks ---
> On Tue, 27 Mar 2001, Joris Robijn wrote:
>=20
> > > >> value =3D get_parameter_int( "key", defaultvalue );
> > > >
> > > >Nice. Should this only available while the config is read or over the
> > > >complete lifetime of the server ?
> > >=20
> > > I guess over the complete lifetime of the driver,
> > > but most driver will only read this at init time. ;-)
> >=20
> > Wo. Ehm we don't want a windoze registry at least :)
>=20
> 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 ...

But it's quite possible that the server itself (or the menu system)
could decide it wants to save its options. Or do we want this feature?

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

Example. Initial configuration snippet:

[server]
screenlife=3D5
fps=3D8
heartbeat=3Dno

Now suppose the user dorks around in the menus and changes the
screenlife to 10 seconds, and turns the heartbeat on. Now suppose s/he
likes what s/he sees and wants to save those settings.

Now imagine LCDd's menus including a "Save Settings" option. Of course
LCDd may not even *have* write access to the config file, so in that
case it may just have to write a new config file to a temporary spot, or
it might not even be worth doing.

'Tis a thought, though :)

> > > >In the latter case we should use a hash to store config in the LCDd.
> > >=20
> > > I have been suggestion hash for that,
> > > then someone said we only need it the protocol,
> > > now you tell me we need it again for config file... ;-)
> >=20
> > Yeah that's odd ! But let's wait with hashing or not hashing, because=
=20
> > using a hashtable is an optimization. If all is implemenmted well, it=
=20
> > can be added without any other code knowing it. But if we only have 10
>=20
> Yes I agree with you.
>=20
> > sections with 10 keys, using a hashtable would be like using a tractor=
=20
> > in your backyard :)
>=20
> Hmmm, but if you query the config database often then the tractor would be
> useful ?
>=20
> > > If it has to be re-read and that some config of some LCD is change
> > > (baud rate? size? ...) should we reset and reinitialise the driver?
> > >=20
> > > How do we detect changes, how do we tell the driver?
> >=20
> > kill -HUP pid
> > Then it should reread config files, and tell drivers that the config=20
> > has changed. Then they should decide what to do. Is that OK?
>=20
> Yes it's ok. But what with removed/added drivers ?

A removed driver wouldn't be a big deal if a similar screen was
available that LCDd could transparently "move" the other clients'
screens to. If a driver is yanked though for a unique display (i.e. the
only 20x4 available), then the clients should probably be informed.

Added drivers are easy; if they're similar to others, start moving
screens to them. If they're different, add it to the list clients get
when they ask.

> > I don't know how we should tell the clients. We could do a EVENT=20
> > TYPE=3Dsighup or something.
>=20
> I think we should inform all clients about the start and end (end with the
> last seen cmd id ?) so they know that all msg in this intervall will be
> lost.

A good idea. The protocol should definitely include flow control like
that.

> > > What do we do with current client?
> >=20
> > No problem, they just don't do config yet.
>=20
> When I remove the input driver for the key which are registered by a
> client ....

The client gets told "your key is not available."

--
William W. Ferrell, Senior System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202   1.303.223.0564

Public key available:
  gpg --keyserver certserver.pgp.com --recv-key 7478FC7A

Hello.  I know the divorce rate among unmarried Catholic Alaskan females!!

--UTZ8bGhNySVQ9LYl
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjrAy28ACgkQgAeqhXR4/HqLBACg8n6HOSvytec+dKNTphF91wBi
bRoAoJCJ2dxTFMYNYGD89lVT58TGhpBB
=ngVm
-----END PGP SIGNATURE-----


--UTZ8bGhNySVQ9LYl
Content-Type: text/plain; charset=


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