[mythtv] Edit Recording Schedules patch for services api dvr endpoint (0.26 and master)

[MythTV Dev Tikinou]

David,

Thanks for the feedback, here are my comments:

On Fri, Apr 19, 2013 at 4:00 PM, David Engel <david at istwok.net> wrote:

> On Thu, Apr 18, 2013 at 01:30:24PM -0400, MythTV Dev Tikinou wrote:
> > We created two patches for fixes/0.26 and master, they are under ticket
> > 11495 (http://code.mythtv.org/trac/ticket/1149<
> http://code.mythtv.org/trac/ticket/11491>
> > 5)
> >
> > The patch for fixes/0.26 backports the changes from the master branch dvr
> > endpoint and adds a method to allow editing of existing recording
> schedules.
>
> It's very doubtful any services changes for 0.26 will be accepted.
> Like with the database schema and MythTV protocol, we try very hard
> not to change things like this on released versions unless absolutely
> necessary.


I figured I would give it a shot, given that it was not impacting other
features :)


> > The patch for master just add the editing method for recording schedules
>
> Here are my current thoughts on how to proceed.  Note that I'm not
> sure this is the best way, but I can't think of a better one way at
> the moment.  As I said on IRC, any work you'd like to do on this would
> be welcomed.  If you can't, I will try to get to it when I can.
>
> UpdateRecordSchedule():
>
> The FindId parameter should be removed.  It doesn't need to be visible
> to the user.  SearchType could be removed, too as it shouldn't ever
> change, but I'm inclined to leave it in for now to keep the parameter
> list very similar to AddRecordSchedule().
>
> New Title, Subtitle, Description, Category, StartTime, EndTime,
> SeriesId, ProgramId, ChannelId, Station, FindDay and FindTime
> parameters should be added.  This is needed to support the full
> recording rule functionality.
>
> There needs to be a *lot* of sanity checking to make sure all of the
> changes are valid before the updated rule is saved.  That sanity
> checking should probably be done in the RecordingRule class rather
> than in the services layer.
>
>
Sounds good, I will make the modifications to the parameter list;
is there a class where the sanity checks are done when mythfrontend updates
schedules ?


> AddRecordSchedule():
>
> Like with UpdateRecordSchedule(), the FindId parameter should be
> removed.
>
> New Title, Subtitle, Description, Category, EndTime, SeriesId,
> ProgramId, Station, FindDay and FindTime parameters should be added.
> Like with UpdateRecordSchedule(), this is needed to support the full
> recording rule functionality.
>
> Also like with UpdateRecordSchedule(), there needs to be a lot of
> sanity checking, probably in the RecordingRule class.
>
>
Sounds good, I will address this at the same time as I address the Update
method...


> GetRecordSchedule():
>
> I'd really, really, really like to have a way for the backend to
> create initial rules for various situations and give them to the
> clients for editing.  This is in contrast to each client creating each
> new rule from scratch and using it's own defaults.  I haven't fully
> thought this trhough yet, but I think GetRecordSchedule() could be
> overloaded with some extra, optional parameters and accomplilsh it.
>
> Add ChannelId and StartTime parameters.  If provided, the returned
> rule (as yet unsaved) will be updated according with values from the
> program at that time/channel.
>
> Add a ParentId parameter.  If provided along with ChannelId and
> StartTime, the returned rule will be updated for use as an override
> rule.
>
> Add a SearchType parameter.  If provided, and the others aren't, a
> suitable search (or manual) rule of the appropriate type will be
> returned.
>
> The client can then edit the rule returned from GetRecordSchedule() as
> desired and then call either AddRecordSchedule() or
> UpdateRecordSchedule() to save the changes.
>
>
I like that idea, however I will not put it in the next patch yet; until
the workflow details are nailed down.

Sebastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130420/cee509ec/attachment.html>