LCDproc development and user support list

Text archives Help


[Lcdproc] LCDd, inetd, and Archeology (was: RE: Clients for dummies!)


Chronological Thread 
  • From: peter at adpm.de (Peter Marschall)
  • Subject: [Lcdproc] LCDd, inetd, and Archeology (was: RE: Clients for dummies!)
  • Date: Sat, 22 Nov 2008 18:00:52 +0100

Hi,

On Sunday, 16. November 2008, Gary R. Van Sickle wrote:
> That was my thought when I first found that out when writing my own client.
> Now, archaicness in-and-of-itself isn't necessarily a problem (or none of
> us would be using *nix!), but what is a problem is LCDd's run-time
> dependency on inetd. Is there a reason why LCDproc doesn't use unix domain
> sockets or named pipes or something else a little more local?

Please don't disseminate false information.

LCDproc does not depend on inetd.

How do you come to this observation.

> There are two primary use cases for LCDproc:
>
> 1. As a secondary display for some local system state information (or
> equivalently, some non-local state that has been obtained through other
> means and made local):
> [ ...]
>
> 2. As a primary display for "headless" and embedded systems:
> [ ...]
>
> I don't really consider the situation where LCDd is connected to by some
> outside agent over the network as a real use case. Just because one can do
> a thing doesn't mean it makes much sense, and in this case the ability to
> do this is more of a side-effect of the implementation that anything else.
> If this is intended to be a real use case, sending the info over the
> internet in-the-clear via telnet is probably not the best choice of IPC
> here either.

This is your personal opinion.
For me, the client-server architecture or LCDproc was the main reason to
use it and to develop for it.

What about having one display but multiple systems ?
E.g. a NSLU2 and another headless machine, both being on a trusted
environment.

> [...]
>
> In order to be all things to all people, It Would Be Nice(tm) if LCDproc
> had an architecture more like this:
>
> LCDd <-some_local_IPC_protocol-> telnet_interface_client_d
> <-current_LCDproc_client_language->
> current_LCDproc_clients_which_use_the_telnet_interface
> <-some_local_IPC_protocol->
> new_LCDproc_client_with_no_need_for_telnet_1
> <-some_local_IPC_protocol->
> new_LCDproc_client_with_no_need_for_telnet_2

Sorry, this is too terse for me to understand.

I am aware that the current protocol has a lot of disadvantages:
- cleartext, not encrypted
Yes, I want the network protocol ;-)
- no authentication
This should be in a network protocol.
- widget commands could get some updates
Here are some of the things that I consider unfortunate:
- the position of a widget should be determined when
defining it, so that when using it you do not need to
tell where to position it
- all widgets should have a size, that limits the output
- bar widgets should give their length in percent / per mille
instead of pixel columns
- ...

Unfortunately it is not possible to change it without breaking
compatibility with older clients.
That's why this will not happen within the 0.5.x series of
LCDproc.

Regards
Peter

--
Peter Marschall
peter at adpm.de




Archive powered by MHonArc 2.6.18.

Top of page