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: Fri, 08 Sep 2000 11:11:23 -0600

* Matt
(madmatt AT bits.bris.ac.uk)'s
mailer blew these chunks:
> William W. Ferrell wrote:
>
> | * Matt
> (madmatt AT bits.bris.ac.uk)'s
> mailer blew these chunks:
> | >
> | > 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
> | >
> | > Does this seem reasonable?
> |
> | Very. I *do* want to keep the sockets and lists in a library though.
> | Probaly separate libraries :)
>
> Oh that's all right then :)
>
> | 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.
>
> Oh, if the client will be using it, then fair enough. I was just woried
> if the clients weren't going to use it, it'd make the library bigger than
> necessary.
>
> | 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 ;)
>
> Um, I was a bit limited by the realms of ASCII art. Each driver is a lib,
> which links in the common functions from another lib, (which incidentally
> would be installed somewhere in /usr/local/... for driver development).
> And make the client lib contain all the socket stuff for the C people, and
> make a suitable Perl module as well, and the equivalent for any other
> languages, python, etc.

Okay, got it. Sounds good :)

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

I
am
not
very
happy
acting
pleased
whenever
prominent
scientists
overmagnify
intellectual
enlightenment

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