[Lcdproc] Overloading the 'output' token

[Rene Wagner]

[Merely take the following as food for thought. I haven't seen/touched
 any LCDproc code in ages...]

On Wed, 2009-02-11 at 19:56 -0500, Ethan Dicks wrote:
> Given the existing client-server protocol we have to work with, I can't envison
> a solution to the icon/GPO problem that handles all existing displays, let alone
> any that might come to market in the near future.
> 
> The present protocol is quite old and is unextensible.  It's also not
> going to be
> changed for any 0.5.x version of LCDproc, so I didn't propose any changes to
> the protocol itself.

It's a thin line. Adding to the protocol for each and every slight
variation to the way displays have worked in the past is probably not a
good idea. Squeezing new functionality into the existing protocol on the
other hand can be problematic, too.

Personally, I'd prefer a clean protocol in the sense that it represents
what the individual commands actually do even if that requires protocol
extensions. Additional commands don't break compatibility after all.

I'm not saying this is the definite answer to your question, but I
thought I'd mention it as an option.

> I do like the fact that I can write clients that are mostly display-agnostic
> (by querying the geometry and perhaps altering what widgets are created
> as a result).  I would love to see future versions of LCDproc enhance the
> communications between server and client about what "features" the server
> is prepared to support (a bazillion icons, GPOs, multi-color this and that,
> Dallas 1-wire, less textual interpretation of graphic displays, etc., etc.)  For
> now, though, only small steps are possible.

I like the idea. Many widely used protocols have this sort of mechanism:
a baseline "always supported" protocol core and a way of negotiating
what other optional features are supported.

Maybe this is indeed more of a long term goal, but maybe it's worth
considering whether the type of functionality mentioned in this thread 
can be wrapped in a new command or two more elegantly than by means of
"output".

In any case, keep up the good work!

Regards,

Rene