LCDproc development and user support list

Text archives Help

[lcdproc] Current developpement question...

Chronological Thread 
  • From: natey AT (Nathan Yawn)
  • Subject: [lcdproc] Current developpement question...
  • Date: Sun, 17 Sep 2000 21:07:30 -0500

> Could someone else (not Matt or me) have a look and try to understand what I
> am talking about.
> Do you see the point or not?

Lemme take a stab at this here...

OK, hardware setup: you have a Linux/UNIX PC that you wish to monitor
(or at least, on which to run the LCDd server). You also have a piece
of Cisco hardware, which has an RS-232 serial port and also a network
interface (I'll assume ethernet). There is a particular address, port,
and protocol which can be access via the ethernet interface which will
send data out the Cisco's serial port, and this same protocol can read
data back in.

You want to attach a serial LCD to the serial port of the Cisco, then
run the LCDproc server on the Linux PC, and have it display to the LCD
attached to the Cisco's serial port.

This strikes me as a reasonable thing to do. It also strikes me as
something best done solely at the driver level. The server through
client levels shouldn't be affected at all. I think you're also
suggesting that perhaps all the drivers should be written with a modular
layer at the very bottom, so that it would be easy to make the output of
the MtxOrb driver go to the Cisco, instead of to the serial port. This
isn't unreasonable, seeing as one never knows what sort of display you
may want to plug into the Cisco. However, it would be a lot of work and
complexity for a very specific case. I realize that this case could be
abstracted to something rather more general, but again, it's a fair
amount of work and another layer of complexity, and KISS seems to be the
theme lately...

Is this pretty much what you've been trying to say?

Two more things I'd like to add...first, the telnet server is a pretty
interesting idea, that could likewise be implemented entirely as a
driver. When initiallized, the driver could open up a TCP port and wait
for TELNET connections (it might have to fork a seperate process so it
could run continuously), then display framebuffer data via curses, as
David suggests. The only caveat is that a client would specifically
need to ask to display to use the TELNET "display".

The other thing I'd like to suggest is that LCDproc is most useful
used locally, both client and server on the same system, to monitor a
headless box. There must be far better tools available to monitor a
machine via network, right? I'm all for doing "Cool stuff," and using
netowrk sockets between client and server is just a good idea, but I
kinda think that doing any fancier networking stuff sorta falls under
"feature creep." Am I way off base here?

Nathan Yawn
natey AT

To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT

Archive powered by MHonArc 2.6.18.

Top of page