LCDproc development and user support list

Text archives Help


[lcdproc] Idea for driver handling...


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

* Matt
(madmatt AT bits.bris.ac.uk)'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.

Yup.

> 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 certserver.pgp.com --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 lists.omnipotent.net


Archive powered by MHonArc 2.6.18.

Top of page