LCDproc development and user support list

Text archives Help


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


Chronological Thread 
  • From: g.r.vansickle at worldnet.att.net (Gary R. Van Sickle)
  • Subject: [Lcdproc] LCDd, inetd, and Archeology (was: RE: Clients for dummies!)
  • Date: Sat, 15 Nov 2008 17:55:22 -0600

> From: hansfong
>
> Citeren Andrew Grover :
>
> > Look at the LCDd manpage. The client protocol is human-readable, so
> > you can use whatever language you want to telnet to localhost port
> > 13666 and send commands.
>
> Isn't that a bit archaic? I haven't been using telnet for
> ages and I thought the use of telnet was depreciated.
>

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?

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):
- Audaproc
- hddtemp-lcd
- amulestats
- lcd-stuff
- lcdvc
- log4j
- Zinf
- lcd-nut
- lcdwho
- Tim Niemueller's SETI at home stats client
- RC5 Stats Client
- imonlcd

2. As a primary display for "headless" and embedded systems:
- IRMP3
- VDR
- netLCDclient
- MP3SB (FWICT anyway)
- My application (a carputer)

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.

In the situations described in #1 above, it is probably largely immaterial
how LCDproc client-server communications happen, whether it be telnet,
sockets, named pipes, smoke signals, or whatever, since the systems in
question will often have a full-on networking stack running anyway. Still,
why introduce a dependency when you don't have to?

In the #2 cases it does become a significant issue. In the dedicated
MP3/PVR/many-other-embedded-application role, time-to-boot is a primary
concern, and the system may not even have any network connectivity.
Requiring inetd to be installed and having to wait for it load and figure
out there's no CAT-5 for it to look at, just so I can talk to my 20x4 LCD,
is clearly wasteful.

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

--
Gary R. Van Sickle






Archive powered by MHonArc 2.6.18.

Top of page