LCDproc development and user support list

Text archives Help


[lcdproc] Protocol changes / cursor control feature


Chronological Thread 
  • From: andre.breiler AT rd.bbc.co.uk (Andre Breiler)
  • Subject: [lcdproc] Protocol changes / cursor control feature
  • Date: Sat, 16 Jun 2001 16:14:06 +0100 (BST)

On Fri, 15 Jun 2001, William W. Ferrell wrote:

> I was mostly digging through server/client_functions.c to make sure I had
> a firm grasp on how I wanted to implement the recently requested ability
> to control the on/off state, blinking on/off state, and position of the
> hardware cursor available in some of the displays we support.
>
> It occured to me that now's as good a time as any to try to actually
> standardize the protocol a little bit. Of course this means breaking

This is planed for v0.5 (the protocol will be replaced with a complete
different proto as long as I can see).
This was the reason I only changed the proto in a way which doesn't break
the clients.

> compatibility (I *think* ... I'm not entirely sure the changes I'm making
> right now are going to kill anything; the LCDproc client at least still
> runs even with my server modifications).
>
> Basically, it shouldn't say "huh?" ever :) It was cute, and amusing, but
> it's not a very clean way to do this. The server needs to be more
> informative than it is.

Last time I digged through the code here were only two results possible
ERROR and SUCCESS.
So I decided that I won't change the huh? and only add the success.
The reason for the success is that I need some sort of info if an command
was successful (befor it was defined that if the server doesn't respond
with an huh? it was sucessful) to get ride of the timeouts.

> So far, I've decided on this scheme for messages and errors. Here's three
> examples:
>
> 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.

> INFO: screen_add: Succeeded
>
> I trust these are self-explanatory; errors are fatal (the operation didn't
> succeed), warnings are non-fatal (the operation may or may not succeed;
> the server will bark an error back if the operation subsequently fails),
> info messages are just informative.
>
> The server's response to "hello" has changed too (I appended "INFO: " to
> the beginning of it.
>
> This of course breaks any client that requires seeing "connect LCDproc"
> right at the start of the server's response to "hello". Ugh. I haven't
> committed these changes to CVS yet since I wanted to bounce them off the
> people here first.

Yes this will break some clients (e.g. mine which collects the protocol
version from the connect message and tries to speak the protocol).

> Standardizing on this messaging scheme will make a number of things
> easier. For one thing clients don't have to check as hard for problems; a
> "dumb" client can just see if it got "ERROR:" back when it tries to add a
> new screen (then exits), or if it got "INFO:" (or "WARNING:" followed by
> "INFO:") back instead (it continues).

Ok if here are any operation which have the abability to produce only a
warning then this makes sense.
A client knows his last command and knows if an error (huh?) is fatal or
not and as long the WARNING,INFO msgs are not standardized (e.g. like
SMTP) the client gets not a better position than before.

If you change the protocol so fundamentally then you should also add an
id for every command so that I can send a load of commands to the server
and check the responses afterwards.

> Ideally, clients should parse the server response to make sure what they
> asked for actually happened, but since the server previously just said
> "success" to most things or "huh? you have to ..." to most errors, it
> wasn't too easy to implement this (and impossible to verify that a success

Sure it isn't optimal but here are only this to choices (you got what you
asked for or it failed) at the moment unless someone changed the most
parts of the server (but I didn't see anything like this on the
maillinglist) so that you can track an command until it's completed by the
last thing in the chain (e.g. the driver changed the backlight).
Here also the problem that you don't know that the display does itself so
that you can't be sure that you see what you expect on the display.

> 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.

> Now, as for the cursor control feature, I think the following changes are
> required (given my digging through the code; feel free to correct me and
> save me hours of banging my head into a wall if I'm wrong ;):
>
> * Each driver needs the following new functions (whether they're actual
> functions or just stubs doesn't particularly matter):

Hmm, each driver which likes to support this.

> - lcd_cursor_on
> - lcd_cursor_off
> - lcd_cursor_blink_on
> - lcd_cursor_blink_off
> - lcd_cursor_positition (int * x, int * y)

I think the last one is allready here for the case that you would like
to write an char on a specific position on the screen.

> * servers/client_functions.c needs to implement new protocol calls:
>
> - Ideally, screen_set (which for now just sets the screen's name)
> should handle the new features, since this is definitely related
> to a specific screen. New arguments to screen_set would be:
>
> - show_cursor <[on|true|yes]|[off|false|no]>
> - blink_cursor <[on|true|yes]|[off|false|no]>
> - cursor_pos <x> <y>

I agree with you. But please implement these params as optional things.

> * The "base" LCD driver (that provides the stubs for drivers that don't want
> to (or can't) implement a specific call, and calls each driver's init())
> needs to be changed so it knows about the five new calls, and to provide
> basic stubs for those functions.
>
> I don't quite know yet if I've got everything sorted; is there more that
> needs to be done to implement these features? Obviously the drivers have
> to be updated to support the calls when their hardware allows, but
> otherwise, have we got everything?

Yes I think you got all the pieces. You have to decide if the server or
the driver should do the (cursor on/off on display refresh).
I'd do it in the serever because the refresh is initiated by the server.

> Wednesday's bus ride home changing the server's response messages and
> haven't gotten through that yet (they're *everywhere*!). I've been

Yes they are in three files I know.
And yes a definition for result responses would be fine.
As I stated while ago I think the best is to have a numeric response like
HTTP or SMTP which specifies the type of error/success followed by the id
of the command and followed by a text description of the response code.
In this case the client knows based on the value how critical and which
type of result he got and can decide what to do.
Main adavntage over text that you have not to parse the text (which is not
as easy as to parse a number).

> thinking we should figure out a way to get those specific strings out of
> the actual client_functions.c codespace (and other bits here and there).
> I'm not all that experienced in C, so what's the best way to put those
> messages all in one place? I don't necessarily want to do the
> internationalization thing (it's a protocol, not a means of user
> interaction), but it'd be nice to have all those messages in one file
> where I could screw it all up with fewer edits >:).
>
> Input welcome.

We can do an error.[ch] which defines a set of error codes sorted by type
and level. To every code is a string defined.
And here will be an faunction which spits out the error, like.
print_stat(int s, int cmd_id, int status, char *info, ...)
where:
s - socket to write
cmd_id - id for the command to which this status belongs (supplied
by the client whith the command)
status - error code itself
info - additional text which gets printed after the text defined
by the error code.
I think the best is if this is an printf style format
string.

Bye Andre'
--
Andre' Breiler | Tel: +44 1737 839532
BBC Internet Services | Email:
andre.breiler AT rd.bbc.co.uk
Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/
Mail me. Don't phone if possible. And use a Subject line.



-----------------------------------------------------------
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