LCDproc development and user support list

Text archives Help


[lcdproc] Current developpement question...


Chronological Thread 
  • From: wwf AT frontierdev.com (William W. Ferrell)
  • Subject: [lcdproc] Current developpement question...
  • Date: Sun, 17 Sep 2000 21:18:04 -0600

* Nathan Yawn
(natey AT hcis.net)'s
mailer blew these chunks:
>
> 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?

Seems to be what *I've* gathered from this discussion. I like the idea,
and think it's worth implementing (or at the very least, planning). It
might end up being a wishlist thing instead of a todo.

So long as we design things right, adding this feature shouldn't be too
difficult later when we've got the time.

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

An alternative to this is to combine multiple displays onto a curses
terminal. Usually a VT100 (or whatever) is 80x24. You can fit quite a
few 20x4 alphanumeric displays on that, 3x5 at least.

It would definitely be a specialized driver.

Maybe we're going about this wrong. Perhaps we should just let clients
connect to the server, get a list of screens, then request the current
framebuffer (or ask that the server send every framebuffer change to the
client). Of course this introduces its own problems (how does a client
get its information to a real display?).

I'm beginning to think this is a *very* specialized use of LCDproc that
won't be mainstream; maybe we should just let those who want to do it
like this write their own stuff to shunt data from LCDd to a display on
a Cisco router.

*shrug* I think I'm floundering here so I'll let someone else run with
this idea for a bit now :)

> The other thing I'd like to suggest is that LCDproc is most useful
> when
> 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?

No, feature creep is a bit of a danger here. We've got a perfect chance
to rebuild LCDproc *exactly* how everybody wants it (users and
developers), so we're naturally gonna throw every idea into the melting
pot and sift out the ones that don't make sense later.

In *this* instance, though, I think it's a good idea. This is still the
design phase (although there's already a bit of coding going on :), so
there's lots of room for change. There's plenty of ways to achieve the
same effects; sorting out which one is the right approach for our
purposes is what's important.

--
William W. Ferrell, 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

Beggars should be no choosers.
-- John Heywood

Attachment: pgp5t2WlnhZEj.pgp
Description: PGP signature


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


Archive powered by MHonArc 2.6.18.

Top of page