LCDproc development and user support list

Text archives Help


[LCDproc] Intro and current status Q?


Chronological Thread 
  • From: wwf AT frontierdev.com (William W. Ferrell)
  • Subject: [LCDproc] Intro and current status Q?
  • Date: Thu, 07 Sep 2000 12:06:49 -0600

* Matt
(madmatt AT bits.bris.ac.uk)'s
mailer blew these chunks:
> William W. Ferrell wrote:
>
> | So far I've just been taking my first stab at documenting the protocol.
> | New doubly-linked list code is finished, just need to make it a library,
> | and the socket code is close to finished. Again, it will become a
> | library. I think we're not gonna need a "shared" directory anymore --
> | anything that's shared between client and server is going to be stuffed
> | into a library. Sound good, anyone?
>
> Hmm, I've been trying to figure out what uses the libraries where and I've
> come up with the following diagram which hopefully explains how I envisage
> it:
>
> LCDproc
> / \
> Server Client
> / \ / / | \ \
> Output Input C #1 C #2 C #X Perl #1 Perl #X
> / | \ / \ \ | / \ /
> MtxOrb CFontz hd44780 Joystick IrMan libLCDclient.so LCDclient.pm
> \ \ | / /
> libLCDdrivers.so
>
> So unless we need double-linked lists in the driver code, it can probably
> stay in the server code, same for socket stuff, although you would want
> the socket code in the client lib for the C clients anyway.
>
> Does this seem reasonable?

Very. I *do* want to keep the sockets and lists in a library though.
Probaly separate libraries :)

The linked list stuff is a freebie -- the server uses it and the stock
LCDproc client will use it too, so why not make it a library to get
some of that mythical "reusable code" stuff going? :) Same goes for
socket code.

So would each driver be its own library, or would all drivers get
stuffed into a single library (your diagram isn't perfectly clear on
that point, unless I'm missing something ;)

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

The aim of science is to seek the simplest explanations of complex
facts. Seek simplicity and distrust it.
-- Whitehead.

Attachment: pgph4xrdtDdzK.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