[vdr] Concerns about changing the API-definition of 'cStatus::Replaying()' and 'cStatus::Recording()' of VDR?

Udo Richter udo_richter at gmx.de
Sun Dec 18 18:39:28 CET 2005

Klaus Schmidinger wrote:
>   void Recording(const cDevice *Device, const char *Name)
>   void Recording(const cDevice *Device, const cRecording* Recording)
>   void Recording(const cDevice *Device, const char *FileName)
>   void Recording(const cDevice *Device, const char *Name, const char
> *FileName)
> Same goes for Replaying(), of course.
> To me it's all the same, so let's here the votes.

I'll start backwards, because I think its easier for Replaying():

  void Replaying(const cControl *Control, const char *Name);

There we have a nice cControl passed, which is a cReplayControl in the
VDR case, with things like cReplayControl::fileName etc.
Without changes, we could mess with dynamic_cast<> to get back
cReplayControl. More elegant would be to add virtual const char*
cControl::FileName() and maybe cControl::URI() and cControl::Title() and
similar, so any control implementation can give away more information
about itself.

For recordings, only a cDevice is passed. The logical counterpart would
be to pass a pointer to cRecordControl, cRecorder or cReceiver - and
extend its interface too.
There is no generic cRecordControl class, the actual cRecordControl
directly implements VDR's own recorder. Question is, do we have other
recordings, except VDR's own ones?

For compatibility, what about something like this:

  virtual void Recording_V2(const cRecordControl *Control) {
  virtual void Recording(const cDevice *Device, const char *Name) {}

That way compatibility is kept unless Recording_V2 is replaced with an
own implementation. (names and parameters are just an example)



More information about the vdr mailing list