[lcdproc] TCP or .so

[Andre Breiler]

On Mon, 26 Mar 2001, William W. Ferrell wrote:

> --- andreb@rd.bbc.co.uk'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).
> 
> ...only instead, linked at runtime, not compile time.

Yes, right. But here are platforms who don't support this. On these it's
the same as 0.4

> > > > other thing is maintaining synchronisation between LCDd and the drivers,
> > > When they should have lost connection, they can try to reconnect. If 
> > 
> > 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

Yes, I was thinking on something like: "I'm /dev/tss/3@FQDN".

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

The id should unique per display (see above) so if this ID is allready
active and known, then the driver will be told to go away.

And yes, we should use this ID in the config file for LCDd for:
- allow/deny
- build big displays

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

Yes but we are talking about the connection mode not the lib.
The lib driver should _nerver_ die if inlcuded as lib but it can die if
distributed.
I would also prefer that the wrapper connects to the driver not the driver
to the server because the connection lost case is easier to implement on
the driver side.

> > > that succeeds, LCDd should send the contents again, so they get'in-
> > > sync' again. LCDd knows how to 'place' the various displays (above, 
> > > 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?)

I agree with you that the driver should request the update if he is out of
sync.
I think in most cases a screen layout change will fore the LCDd to send
the complete buffer to the driver.

Bye Andre
-- 
Andre' Breiler                       |   Tel: +44 1737 839532
BBC Internet Services                | Email: andre.breiler@rd.bbc.co.uk 
Kingswood Warren,Tadworth,Surrey,UK  |   URL: http://support.bbc.co.uk/
Mail me.  Don't phone if possible. And use a Subject line.



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