LCDproc development and user support list

Text archives Help

[lcdproc] Protocol changes / cursor control feature

Chronological Thread 
  • From: wwf AT (William W. Ferrell)
  • Subject: [lcdproc] Protocol changes / cursor control feature
  • Date: Mon, 18 Jun 2001 10:45:29 -0600

andre.breiler AT
wrote ---
> On Sat, 16 Jun 2001, William W. Ferrell wrote:
> > ---
> > andre.breiler AT
> > wrote ---
> > > On Fri, 15 Jun 2001, William W. Ferrell wrote:
> > >
> > > > ERROR: screen_add: Too few arguments (expected 2, got 1)
> > > > WARNING: screen_add: Too many arguments (expected 2, got 3)
> > >
> > > Last time I digged through the code your warning would be the same as
> > > error becoause the command dien't succeed but I will look again.
> >
> > Well, it would most likely be fatal, but isn't necessarily. I figured
> > changing "too many arguments" into a warning since there's enough
> > arguments to at least *try* to complete the command (just ignore the
> > rest). It's probably stupid to do this now, as there's next to no sanity
> > checking on the arguments sent by the client.
> Ok, I see you point. You are defining a few params as optional.
> Yes this makes sense and someone should remember this for v0.5 .

I will :)

> Yes right. With a small addition as ID for the command. So that I can
> send a bulk of commands to the server and have not to wait for the
> response after every command. The advantage would be that I can get ride
> off of the network latency.
> e.g. I can send:
> screen_add cmdid=1 name=main
> screen_add cmdid=2 name=options
> screen_add cmdid=3 name=misc
> and then collect the responses
> 100 1 OK screen main successful created.
> 100 2 OK screen options successful created.
> 302 3 DELAYED Screen queue locked. creation of screen misc delayed.
> 100 3 OK screen misc created.

Brilliant! I hadn't thought of this. This way a client can just totally
ignore the command ID stuff if it wants to stay simple, or it can use it
for sanity checking. Very good idea.

> > > > really succeeded at doing what was intended). This change makes that
> > > > workable.
> > >
> > > Maybe I oversee something but I think you solution does the same as it
> > > was
> > > implemented before but will break most clients.
> >
> > Well this was trying to move to the next version of the protocol. The
> > folks on the list are right, though, this should be implemented in v0.5,
> > not in v0.4.x.
> Hmm someone should collect all the ideas from the maillinglist into an
> document (I stopped to do this half way because the lack of time).

I have been. It's going slowly; I'm trying to also write the new protocol
specification as I go as well. I keep having to make revisions ;) A side
effect of this is that I keep trying to creep v0.5 features into v0.4
(namely the protocol changes). I have to stop trying to do that.

> > Okay, but what should the defaults be? show_cursor & blink_cursor false?
> > cursor_pos "wherever the server leaves it"? :)
> Yes I think these would be the best because this is what the current
> server version does.


> > It has to stay in the server; we have to keep cursor state for each screen
> > now, even if it's just to say "this screen doesn't want the cursor turned
> > on and doesn't care where the cursor is."
> >
> > For screens that do, we have to turn on the cursor right as we send the
> > first frame, then make sure for every frame afterwards we send the cursor
> > position command *after* everything else.
> You are right but I guess you mean turn the cursor off until we finished
> writing to the screen then set the position and turn the cursor on.
> Otherwise we will get a flickering cursor.

That's a reasonable default, but I'd like to allow the client to specify
that itself if it wants to. People might want a flickering cursor, and
it's certainly not going to be painful to implement having a choice.

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

Public key available:
gpg --keyserver --recv-key 7478FC7A

To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT

Archive powered by MHonArc 2.6.18.

Top of page