LCDproc development and user support list

Text archives Help


[lcdproc] Current developpement question...


Chronological Thread 
  • From: wwf AT frontierdev.com (William W. Ferrell)
  • Subject: [lcdproc] Current developpement question...
  • Date: Fri, 15 Sep 2000 08:09:25 -0600

* David Glaude
(dglaude AT netbrain.be)'s
mailer blew these chunks:
>
>
> -----Original Message-----
> >From: William W. Ferrell
> >[mailto:wwf AT frontierdev.com]
> >Sent: Thursday, September 14, 2000 10:14 PM
> >To: Matt
> >Cc: LCDproc mailing list
> >Subject: Re: [lcdproc] Current developpement question...
>
> >...that can be avoided simply by insisting LCDproc be downed and brought
> >back up when hardware changes occur.
> >
> >That's just too much work for too little gain. Most people are gonna set
> >up their systems and leave them running for days/weeks/months/years.
> >Displays normally won't change that much.
>
> I agree, if any hardware change are done... restart the server.
> And let's try to make the client smart in reconnecting to the new server
> (same place).
> However you sometime have to wait a few minute before the server can
> reconnect to the same TCP port.

The LCDproc client will be bright enough to handle this (hopefully :),
but for other clients, it's up to the author to decide what should
happen. In fact I think the LCDproc should be configurable in that
regard -- what should it do when it receives this?

< ERROR: Disconnecting: server restarting.

A user should be able to choose whether the LCDproc client just bails
when this happens or if it should just sleep for 30 seconds and try
connecting again.

> Now in the opposite direction, we where talking about virtual screen made of
> multiple screen side by side
> or on top of each other. What if you want to change the geometry... restart
> the server?

Interesting question... I'm thinking "yes", restart the server whenever
you change around how a physically attached screen is configured. The
only alternative would be to add display creation/destruction abilities
to the protocol. That could be somewhat dangerous.

This brings up another question -- should *drivers* handle virtual
screens or should the server?

> So if you go for the "restart the server" what is left of dynamic
> screen/driver.
> I still believe that dynamic screen/driver apply for networked screen (Laser
> Jet or telnet monitoring or ...).
> I whould love to be able to telnet the server, say "Hello I am VT100 I want
> a 20*4 copy of lcd screen"
> and get the cursus driver sending a copy of the physical LCD to my remote
> session.
> That way we could build a public LCDd server with news/ticker/weather
> forcast and anyone could:
> 1) Telnet (and resize the screen).
> 2) Attach (how?) with a LCDclient and a physical LCD screen.
> Somehow make LCDd a message broker between client (lcdproc), physical LCD,
> and remote physical/virtual LCD.

We're toying with this idea -- the solution so far is to make a driver
that "pretends" it's a display, but in fact sets up its own socket and
listens for connections. If you wanted to make a driver that speaks
telnet and sends VT100/ANSI/whatever, you could do so.

I wonder about the wisdom of dynamically resizing screens though -- how
do you tell a client, that's just spend a lot of effort sorting out
which display it should use, that its chosen display just doubled in
size? That's certainly not a case *I'd* want to code a client for :)

[Flex/bison mumblings]

> Just to give you my practical experience about flex/bison, here is the
> relevant files from my last small little project relative to the macro
> processing of a language. All of this is on a windows intel platform but
> using GNU tools:
>
> -rw-r--r-- 1 dglaude Administ 17673 Sep 15 00:13 BISON.SIMPLE
> -rw-r--r-- 1 dglaude Administ 3598 Aug 9 08:53 LType.l
> -rw-r--r-- 1 dglaude Administ 46353 Sep 15 00:30 ltype.c
> -rw-r--r-- 1 dglaude Administ 14469 Sep 15 15:06 ltype.o
>
> -rw-r--r-- 1 dglaude Administ 4031 Jul 27 22:51 YType.y
> -rw-r--r-- 1 dglaude Administ 26716 Sep 15 15:05 ytype.c
> -rw-r--r-- 1 dglaude Administ 541 Sep 15 15:05 ytype.h
> -rw-r--r-- 1 dglaude Administ 8214 Sep 15 15:05 ytype.o
>
> More likely the parser for LCDd won't be that big, but for those of you
> focussing on space, the *.o files seems big.

Those actually look rather small ... 22K for a parser isn't too
terrible. The current LCDd is 75663 bytes on my machine, though, so I'm
guessing this would increase a *little*. Then again, LCDd v0.4-pre9
doesn't dynamically load modules either. *shrug* We'll just have to see
how it grows as we move forward.

--
William W. Ferrell, System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202 1.303.223.0564

Public key available:
gpg --keyserver certserver.pgp.com --recv-key 7478FC7A

You can't take damsel here now.

Attachment: pgpLrUphlu2Mx.pgp
Description: PGP signature


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


Archive powered by MHonArc 2.6.18.

Top of page