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

[William W. Ferrell]

--0rSojgWGcpz+ezC3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

--- joris@robijn.net's mailer spewed these beefy chunks ---
> > >> 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 :)
> 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...

Agreed. I definitely think this should always be available.

> > >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
> sections with 10 keys, using a hashtable would be like using a tractor=20
> in your backyard :)

Hey! Tractors are fun >:)

But more seriously, if you recall my first example config file awhile
ago, it was rather bulky. And hash will still be faster than just
tearing through a linked list. :)

> > 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?

I'd also like it to occasionally check the config file. Or do folks
think that's overkill?

> I don't know how we should tell the clients. We could do a EVENT=20
> TYPE=3Dsighup or something.

Yup. A message to the client. Whether it wants to reinit and interrogate
the server again, or wants to barf and exit, or completely ignore the
reset (and probably get booted off by LCDd a few seconds later :) is up
to the client.

> > What do we do with current client?
>=20
> No problem, they just don't do config yet.

Or it reinits.

--
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

I must get out of these wet clothes and into a dry Martini.
		-- Alexander Woolcott

--0rSojgWGcpz+ezC3
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

iEYEARECAAYFAjrAyI8ACgkQgAeqhXR4/HrJCwCfXbqlDlbL2YBwviGjV0Y7Jy/o
lWIAn0LKib8kSeOS6sTAoThGQ0zFrdnA
=aQGs
-----END PGP SIGNATURE-----


--0rSojgWGcpz+ezC3
Content-Type: text/plain; charset=


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