[lcdproc] TCP or .so
William W. Ferrell
Mon, 26 Mar 2001 08:30:00 -0700
Content-Type: text/plain; charset=us-ascii
--- firstname.lastname@example.org's mailer spewed these beefy chunks ---
> On Fri, 23 Mar 2001, Joris Robijn wrote:
> I think the easiest way is the one with shared libs (.so,.dll,.library
> ...) bacause yu can use funtion calls and pass complete structures to the
> client. On platformes without shared library support it's possible to link
> the driver into the daemon (same as in 0.4).
=2E..only instead, linked at runtime, not compile time.
> > > other thing is maintaining synchronisation between LCDd and the drive=
> > When they should have lost connection, they can try to reconnect. If=20
> But the LCDd can't figure out if this new connection belongs to the same
> driver which is allready known (and has died) or a new one (or we need a
> constant unique id per driver).
This is something left to be decided on. A driver will report its name
to LCDd -- if LCDd's already got a driver by that name, do we allow
multiple instances, or tell the new driver to stuff it because it's
already got an instance?
If we go the latter route, it means each driver has to be able to handle
Also, note that regardless of which way we go, if a driver dies and it's
been dynamically loaded as an .so or .DLL into LCDd, LCDd dies too
unless there's something clever I don't know about.
> > that succeeds, LCDd should send the contents again, so they get'in-
> > sync' again. LCDd knows how to 'place' the various displays (above,=20
> > next etc), so when a 'lost' driver reconnects LCDd should recognize it,=
> > and it will place it back where it belonged. Are there other problems ?
> You can't rely on the connection (high latency, small bandwith, data loos,
Right. I think it's up to the driver to request a refresh if it thinks
something's gone nuts, otherwise it can just wait until the next screen
change (I think any change in screens or virtual screen layouts should
force a full frame redraw ... any other opinions about this?)
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
If I were a grave-digger or even a hangman, there are some people I could
work for with a great deal of enjoyment.
-- Douglas Jerrold
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
Content-Type: text/plain; charset=
To unsubscribe from this list send a blank message to