LCDproc development and user support list

Text archives Help

[lcdproc] LCDd suggestions

Chronological Thread 
  • From: Scott Scriven <toykeeper AT> (Scott Scriven)
  • Subject: [lcdproc] LCDd suggestions
  • Date: Thu, 21 Oct 1999 14:55:30 -0600 (MDT)

On Thu, 21 Oct 1999, Thomas Runge wrote:

(The most important stuff is near the bottom)

> I found some inconveniences in the protocol, so I want to suggest
> some improvements.

> - every command sent should get a reply.

Okay. This could be good. The original intent was "no news is
good news", so the server would only notify the client of
errors and events. The only thing I see as being a potential
problem with synchronous communication is that the server will
need a new structure. Currently, it sleeps most of the time
and checks for messages 8 times per second. This won't work if
clients want replies immediately.

We could always go to a threaded model, where the output thread
sleeps most of the time but the client-serving thread is always
handling input...

Another option is to just switch over to an already-established
communication framework, such as CORBA; or even an XML-based
protocol. Just a thought...

Regardless, though, I agree it needs better error messages. :)

> - I don't like, that the statistics screen stays that long open
> blocking the important ones. How about showing it just for
> only 1 sec?

Adjusting the screen timings are a planned feature, but who
knows how long it will be before it's implemented.. I just
adjusted the server screen duration to 1 second, so I wouldn't

> So, whats the status of development for lcdproc? The last update
> was months ago. Did it stop? There are so many features not
> implemented, yet.

Okay, this is probably the most important question. I'll be
completely open about this:

There is one "active" maintainer (me), and nobody else seems to
have both the knowledge and the motivation to update LCDproc.
But, there's a further problem with this...

I've been unfortunately stuck dealing with "real life" instead
of programming. (school, two jobs, etc..) I'm taking leave from
one job starting a couple weeks from now, and intend to use the
extra time to get a couple more releases of LCDproc out.

A somewhat longer-term goal is to get a full LCDproc-0.4 out,
and then start seriously looking for a new maintainer. If I'm
lucky, maybe CmdrTaco will be willing to post a small note
about this (he's gotten at least one free LCD, so maybe he'll
go for it). That would help to find a savvy maintainer, and
add a bit of momentum to kick off the new development phase.
But don't ask him about it *yet*.. :)

As for design, future versions will need quite a bit of
redesign. We have discussed much of this on the list, so many
parts of the program are pretty-well planned. I can repost
some of these if you like, or we can start over again. :)

Most of the existing design problems stem from a common
source... the program's origins. As Choadstre pointed out, it
started as a "hey, that's kinda neat!" project. It was in no
way designed to do most of the things it does now, and my
redesign of it underestimated its future feature requirements.

So, I guess the current status is "I'm going to take time off
work, get off my ass, and get some new releases out."

_ _ _ _ ___ ___ ------------"Use the source, Luke!"---------
( \/ ( \/ (__ (__ ) | Scott Scriven (Toy Keeper / XYZZ) |
\ / \ / // // |
mailto:toykeeper AT
/ \ / / //_ //_ | |
(_/\_(_/ (___(___) | |

To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT

Archive powered by MHonArc 2.6.18.

Top of page