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

[Malcolm Caldwell <malcolm.caldwell@ntu.edu.au>]

On Sun, 2004-09-12 at 18:18 +0200, Klaus Schmidinger wrote:
> Philip Lawatsch wrote:
> > 
> > Klaus Schmidinger wrote:
> > 
> > > No "unique ids", please. I like the plain and simple numbering approach.
> > 
> > Why?
> > I cannot see one drawback by having just one unique id for every timer /
> > recording / whatever.
> > 
> > With your number approach you can get into hell a lot of problems with
> > synchronisation whenever an new item is added or an existing one is
> > moved / deleted.
> > 
> > Imho things will get simpler using unique ids rather than numbers.
> > I mean, you do use pointers to objects instead of indices in one big
> > object array when programming OOP too, dont you?
> > 
> > I'd really like to know why you think that unique ids would make
> > everything more complex.
> 
> Well, it _is_ more complex than plain numbers, isn't it? ;-)
> 
> Besides, this would still leave the problem unsolved that changes could be made
> from the menu and an SVDRP connection at the same time - which I have to
> admit currently _is_ still a loophole...
> 
> Klaus

BTW: I wonder if a 'limited' second connection is useful: the second
connection would be limited by only allowing 'safe' commands.

There are two possibilities:
1. 'safe' commands are all 'list' commands + other 'HITK' 'MESG' etc
2. 'safe' commands are determined by other connection eg.
    I will explain by example: with two svdrp sessions:
    First svdrp      second svdrp        Result
    connect                              OK
                     connects    
    LSTR                                 OK
                     LSTR                OK
    DELR                                 OK - lock 'recordings' commands
                     LSTR                OK -  although 'recordings' are locked but its fine to list!
                     DELR                Fail - 'recordings' commands locked
                     LSTE                OK - lock 'epg' commands
    LSTE                                 OK
                     DELR                Fail - 'recordings' must still be locked (*)
    ....

(*) locks are global and can only be unlocked when all svdrp sessions close.

1 should be very easy to code, 2 only a little harder, and this can be a
first step towards the 'final' implementation with recording numbers
stored as state against the svdrp connection.

Why do this?  It would allow many applications to just continue to work.
At the moment eg. MESG commands will cause vdradmin to miss one of its
polls for no particular reason.  Also, I use svdrp to upload epg fro the
web - if vdradmin happens, by chance to have an open connection I miss
epg for a day. :(

A bit of a hack?  YES.  However, as it just an interim thing it is
probably not too bad.