Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: How to kill an svdrp connection from vdr ?
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...
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
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
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.
Main Index |