[vdr] Re: VDR Patch SVDRP Message Extension

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Detlef Fliegl wrote:
> 
> Hello Klaus,
> 
> this is a patch against vdr-0.98 to display messages on screen via the SVDRP
> protocol. These new commands have been added:
> 
> CMSG <text>
> Display confirmable message on screen (without timeout)
> returns 250 on confirmation, 451 on any other action

Actually the 'Confirm()' call does have a 10 second default
timeout. It would be pretty dangerous to make such a call without
a timeout, because then such a message could block the whole
system forever.

> EMSG <text>
> Display error message on screen (with timeout)
> returns 250 after display timeout
> 
> IMSG <text>
> Display info message on screen (with timeout)
> returns 250 after display timeout
> 
> please add these new commands to your current VDR tree. I use them to display
> status messages of my server (ISDN caller, New Emails waiting etc.)
> 
> http://www1.baycom.de/download/vdr-0.98-svdrp-msg.diff

What I don't like about this is that we suddenly would have _four_ different
commands to send messages (besides the fact that your new ones are not
grouped very well - they should rather be named MSGC, MSGE and MSGI,
respectively). What also bothers me is that the way you have implemented
this the message will come "asynchronously", which means that while the
user is busy working in some menu, he could suddenly be confronted with
a message that has absolutely nothing to do with what he is currently
doing - and that message would be displayed on top of the menu page
he is currently viewing. I'm afraid this could lead to some irritation...

One way to avoid several separate commands for displaying messages would
be to introduce "options" to the MESG command, like

  MESG -i This is an INFO message       (actually this is what MESG does now)
  MESG -e This is an ERROR message
  MESG -c This is a CONFIRMATION message

I guess this shouldn't clash with any existing use of the MESG command, because
it is rather unlikely that anybody is displaying a string that starts with '-'
(well, Murphy says that in fact there _is_ at leats one such person out there,
I wonder who it will be ;-)

However, this still doesn't solve the "asynchronous" message problem.
What if there is currently a pending confirmation message from a menu action of
the user, and this one gets overwritten by an MESG message.
Imagine the user wanted to confirm the initial message, but would NOT want
to confirm the new message. While on his way to pressing OK for the first
message, the second one arrives and thus gets inadvertently confirmed.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________