[vdr] Re: How to kill an svdrp connection from vdr ?

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

Philip Lawatsch wrote:
> 
> Klaus Schmidinger wrote:
> > Philip Lawatsch wrote:
> >
> >>Klaus Schmidinger wrote:
> >>
> >>
> >>>>Imagine what happens if two svdrp connections both want to delete the
> >>>>timer number 13. Most likely timer 13 + 14 will get deleted since you're
> >>>>deleting not a timer number but an index in the list of all timers which
> >>>>will change after the first delete  ....
> >>>>
> >>>>Lots of problems ..
> >>>
> >>>
> >>>As I've stated in a previous post, there is a rather simple
> >>>solution to this. Every SVDRP connection will have to issue an LSTT
> >>>command before it may add, modify or delete a timer. The timer list will
> >>>have a timestamp marking when the last modification was made. If an SVDRP
> >>>connection issues a timer modification command, but the list of timers was
> >>>in some way modified after this sessions last LSTT command, it will get
> >>>an error message, saying that the timers were modified in the meantime,
> >>>and that it should do another LSTT.
> >>
> >>Which for sure will break a lot of applications anyway.
> >>It will for sure require updates to almost any svdrp application working
> >>with timers and recordings since there has been no check for something
> >>like this before.
> >
> >
> > There have always been possible error conditions, like syntax errors
> > or timers being busy when trying to delete them etc, etc, etc.
> >
> > An application that uses SVDRP and does not check for errors is IMHO
> > simply broken.
> 
> Yea, but you require it to handle a new error. You cannot simply say
> Timer not here anymore or syntax error since these are simply not true
> and the program might behave different in this case.
> 
> You have this very special "get list again and send me the new index to
> delete" error ..

So basicly you're saying that there may never be any new error, whatsoever?

If the application doesn't know an error, then it should treat it
as an "unknown error". After all, I _must_ be free to add new error
messages as they become necessary!

Klaus