[lcdproc] LCDproc survey

Charles Steinkuehler cstein@newtek.com
Mon, 14 Aug 2000 10:06:52 -0500


> To help developers gain a better understanding of what you, the
> community want from this excellent piece of software I'm asking you to
> fill out a survey. Really think about these questions, as I, for one,
> will be listening to what everyone has to say. At the end of this week,
> i'll make a web page and post the results along with your comments.
>
> LCDproc Survey======================
> Return to mai3116@rit.edu by Sun, Aug 20, 2000
>
> 1. Prioritize the following design criteria from lowest to highest

 HIGHEST
 Embeddability (can be used in embedded system)
 Flexibility
 Disk usage
 Mem usage
 CPU usage
 Portability
 Backwards compatibility
 LOWEST

> 2. Comment on these Feature requests... what priority we should give it,
> strike it, add more?

> Arbitrary sized displays
Medium

> Virtual displays (think virtual desktops)
Low

> Java clients
High

> Inetd support
Medium

> Non-socket support (unix sockets?)
Low

> Multi-threaded vs. Single Threaded
>     thread-per-client
>         Pros: Simpler to program to understand and maintain
>         Cons: CPU usage starts going up higher and higher after 20+
> clients
>     thread pool, (where there are a maximum amount of threads specified
> but they all distribute the client load among them)
>         Pros: Best way to scale the program
>         Cons: much harder to understand than just thread-per-client or
> single-threaded
>     Pros in general:
>         easier to program, understand
>     Cons in general:
>         needs pthreads... but most posix systems support it (*bsd,
> linux, windows)
I vote thread-per-client
How about running thread-per-client now, with the server spawning or keeping
track of the threads.  Then you could migrate the server to a thread-pool
model later, w/o re-writing all the clients, with only a small increase in
code complexity today :-)

> Dynamic driver loading
Low

> Named pipe support, programs can send commands to /dev/lcd
Medium-High  If this could be used instead of the network socket interface for
the server, some security concerns I have with putting the software on my
firewall and DMZ machines would be lessened...

> Client API
Low...Just give us good docs on the client/server interface...

> (add your own)
Network Bandwidth client!!!

> 3. What clients do you use right now?
Working on a network bandwidth meter client

> 4. What hardware do you use with lcdproc right now?
Parallel port LCD's (HD44780).  I'd like to migrate to a java applet running
on a remote machine.  I use LCDProc to monitor my 'embedded' firewall &
headless web server.  Ideally, I'd like to be able to have many clients see
the same 'display' via java.

> 5. What do you really really really want done in the next release that
> is just annoying the crap outta ya?
1/2 height bar graphs (see http://lcd4linux.sourceforge.net/ )

> 6. Are you interested in helping with the development of clients or
> lcdproc itself?
Sure!  I've already updated the LPT driver code...

> 7. Other comments?
Not at this time...

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



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