[lcdproc] TCP or .so

William W. Ferrell wwf@frontierdev.com
Mon, 26 Mar 2001 08:30:00 -0700


--hwvH6HDNit2nSK4j
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 Fri, 23 Mar 2001, Joris Robijn wrote:
>=20
> 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=
rs,
> > When they should have lost connection, they can try to reconnect. If=20
>=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
multiple screens.

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,=
=20
> > and it will place it back where it belonged. Are there other problems ?
>=20
> 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

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

iEYEARECAAYFAjq/YHgACgkQgAeqhXR4/Hr9WACgwg2GA75voD65ucm4XnFhe3HQ
OBYAoPnYBu8M9NysZzugD9tvbnKU00UW
=aO+N
-----END PGP SIGNATURE-----


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


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