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

[Nicolas Huillard <nhuillard@ghs.fr>]

Klaus Schmidinger a écrit :
> > > Philip Lawatsch wrote:
...
> > > > Klaus Schmidinger wrote:
...
> > > > > 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.
...
> 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!
...

In order to use a generic proxy, the implied modifications are :
* modify VDR in order to check the timestamp of the previous LSTT for 
every ???T command that occurs after it
* modify each application to send the timestamp of the last LSTT to each 
???T command. They simply will receive an error when DELT and we're right.

If a SVDRP-aware proxy is written, then it will implement either the VDR 
side or the application side... or both.
Translated in development tasks :
* either Klaus works at modifying SVDRP handling, but I'm sure he was 
ironic...
* or every application developper implement the necessary stuff
* *and* someone take the proxy task
* *or* someone implement everything in a SVDRP proxy, independently of 
everything else...

(note that this solution is not elegant, as in introduce a stateful 
inspection where it is not mandatory, as someone already said earlier - 
stateless SVDRP would be much more simpler for everyone - that is : if 
state must not be emulated at the client side, like cookies in HTTP)

(I think a real client-server VDR would be a Good Idea - multiple 
clients, multiple servers - separating boths commands, OSD, timers, 
ouput device, etc. Multi-client SVDRP would be the first step)

--
NH