LCDproc development and user support list

Text archives Help

[lcdproc] Idea for driver handling...

Chronological Thread 
  • From: wwf AT (William W. Ferrell)
  • Subject: [lcdproc] Idea for driver handling...
  • Date: Sat, 09 Sep 2000 10:07:38 -0600

* Matt
(madmatt AT's
mailer blew these chunks:
> Ken Robertson wrote:
> | Here is an idea I had been talking with Will about on IRC. I think it
> would be
> | a good idea to have the input and output drivers act as modules, rather
> than
> | all in a library. It work sort of like the kernel handles libraries,
> except
> | they are only loaded at runtime.
> --8<----8<-- SNIP
> | The types of modules I'd suggest would be output and input of course, and
> then
> | client modules. Like if someone wants to add a function to LCDd, when an
> | outside client connects, it would send a command to the server allowing
> it to
> | be turned over to a module. Then when LCDd recieves socket info from it,
> it
> | will get turned over to the module. Like, I've wanted to do a remote LCD
> | feature, where say LCDd is running at home, and I want my LCD at work to
> show
> | the screen from home. Make a client module that will instead of recieving
> | widgets, will trasnmit widgets to a specified connection.
> This was my suggestion from the very start, and how I'm attempting to
> implement them atm :)

Hehehehe :) Scott's right...we need more organization :)

> They're implemented as libraries, but not linked directly into the server
> code, the server loads them at run-time using the dlopen calls.


> For your suggestion, why not create an output driver that instead of
> sending info to an lcd display, send it over a network connection?
> You could then implement an input driver that reads from it...
> Of course, as soon as you start doing network stuff, we get into the
> security problems again...

This is where encryption or at least challenge authentication would come
in handy. A discussion awhile ago seemed to end in a concensus among us
that encrypting chats between clients and server is overkill. I suspect
conversations between a server and a remote display would be similar.

Hell, UDP might even be sufficient for that kind of thing (maybe not,
it's just an idea :). Regardless, we just need to focus on making the
initial authentication secure enough for general use, devoid of
blatantly obvious exploits, and let it go at that.

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 --recv-key 7478FC7A

"Being against torture ought to be sort of a bipartisan thing."
-- Karl Lehenbauer

Attachment: pgpkHkVlCa4lM.pgp
Description: PGP signature

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

Archive powered by MHonArc 2.6.18.

Top of page