LCDproc development and user support list

Text archives Help


[lcdproc] Idea for driver handling...


Chronological Thread 
  • From: madmatt AT bits.bris.ac.uk (Matt)
  • Subject: [lcdproc] Idea for driver handling...
  • Date: Fri, 8 Sep 2000 22:21:43 +0100 (BST)

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 :)

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

Matt



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