[lcdproc] LCDproc v0.5 development, here we go folks :)

[Matt]

Mindaugas Idzelis wrote:

| > > What is this problem with depending on a couple of external libraries?
| > > Look at any project, it's the norm... :)
| >
| > Look at my above comment :)
| >
| > Seriously, LCDproc was meant to be small, and it needs to stay that way.
| > Embedded systems might not have the room (literally) for extra
| > libraries. The average user ain't gonna play with LCDproc if he has to
| > download libblah and libmoreblah, get those working, *then* compile and
| > run LCDproc. It's too much effort.
| 
| I can sense a heated discussion coming on. We have to realize
| something. LCDproc is now client/server. Hopefully it will stay that
| way. The SERVER (the thing running the drivers) doesn't necessarily
| have to super small. It can be 2 megs statically compiled with gnome
| libs if you wanted it to be. The client, however,

I was going to perhaps ask a question along the lines of whether you could
fit all of the XML stuff onto an embedded syustem. But perhaps that's not
required. My point is basically about re-inventing the wheel. Why bother
having to debug your linked-list code, when someone else can do that for
you? Concentrate on writing LCDproc code instead of having to first create
your own library of ancillary functions. I can see the problems with
linking in huge libraries, (Gnome libs for example), which it's best to
avoid...but most libraries are as simple to install as ./configure ; make
; make install. Or is it just me that installs everything from source? Let
autoconf be your friend :)

Has it already been suggested to be able to support stuff using SNMP? I've
just realised I have an HP JetDirect 3-port printserver, that I'm sure I
can furtle with using SNMP. Actually, this is another job for a fantastic
Perl script methinks...

The XML config files seems very suitable, and possibly to wangle it to
store the screen state if that works without too much cruft. I'm not sure
how the client <-> server protocol works though. It looks like it'd take a
lot of effort to transmit a minor change in state...

Oh, and two other related points with regards the other thread. It would
be nice to make the default return recipient the list, I have to do all
sorts of cutting and pasting with Pine to get the address in the right
place. And maybe someone could scratch the offending e-mail address from
the list?

Matt



-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net