LCDproc development and user support list

Text archives Help


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


Chronological Thread 
  • From: andy.grover at gmail.com (Andrew Grover)
  • Subject: [Lcdproc] LCDd, inetd, and Archeology (was: RE: Clients for dummies!)
  • Date: Sun, 16 Nov 2008 22:03:35 -0800

On Sat, Nov 15, 2008 at 3:55 PM, Gary R. Van Sickle
<g.r.vansickle at worldnet.att.net> wrote:
>> 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?

Just because you can use telnet to access lcdproc shouldn't mean that
telnet's archaicness should rub off on lcdproc. It's just a text-based
tcp stream, like http, smtp, or whatever. You could tunnel it over ssh
if you want but I'm sure it was simply why *not* use AF_INET instead
of AF_UNIX? Doesn't hurt, and you get remote clients "for free".

(^^^Complete speculation -- lcdproc has been around for a long time
and I'm a newb, FWIW.)

BTW I don't see a dependency on inetd. If you intend to always have
the lcdproc server running then you can remove inetd and start LCDd
directly.

> 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

It would be trivial to enhance lcdproc to optionally use AF_UNIX. But
then clients would also have to know to try to use it.

However, I do agree that most usage is local. Some areas for
improvement I've been thinking about are some way to make it really
easy to get periodically-updated info on the LCD, maybe using a pull
model. It seems like there are a bunch of clients written in C, Ruby,
Python, etc, so you end up with a bunch of client processes running --
for some types of screens it might make more sense to run a client
periodically for updates instead of requiring it to always be running.
But that would require a different client interface, just like your
proposal.

Regards -- Andy




Archive powered by MHonArc 2.6.18.

Top of page