[mythtv-users] What if...?

[Thomas Mashos]

On Mon, Sep 24, 2012 at 7:18 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 09/20/2012 12:35 PM, Thomas Mashos wrote:
>>
>> I agree with everyone else that removing the frontend wouldn't
>> necessarily help the backend.
>
>
> Agreed.
>
>> The issue that other 3rd party frontends have is that prior to 0.25,
>> they had to keep up with a moving target (the myth protocol). The
>> issue they have now with the services API is that it doesn't offer all
>> of the functionality that the myth protocol offers.
>>
>> What I would like to see is the myth protocol be deprecated and
>> mythfrontend transition to using the services API only. This would
>> force the API to mature to a point that it offers all of the
>> functionality that the myth protocol offers currently, and that 3rd
>> party frontends could be developed and have the same functionality.
>>
>
> FWIW, any protocol will always be a moving target.  Just because we use XML
> or JSON, now, doesn't mean that every client that can use XML/JSON just
> "knows" our services API protocol.  Just try to find the button in Firefox
> that requests a specific recording and starts streaming it to allow
> playback.  (The only way to do this is using a client--i.e. such as the
> client built into the backend's HTTP server--and each client that wants to
> support such behavior must build in support for the feature by knowing the
> proper URI construction, parameters required, ...)
>
> And, there has been no effort to make sure that our services API protocol
> will allow for forwards compatibility of clients (i.e. a client written for
> an old version of MythTV's services API will work with all future versions
> of MythTV services API)--so clients will have to provide their own backwards
> compatibility (clients will need to figure out what services API version the
> backend uses and then speak that version) and users will have to update to a
> client version that speaks their MythTV backend's protocol version (possibly
> among many).  I expect to see changes to our internal
> protocols/libraries/constructs affecting services API...
>
> IMHO, the /only/ reason that services API clients "just work" is because
> we're basically on the first version of the services API.  All the services
> API is doing is changing our custom MythTV protocol from one that uses plain
> text in a MythTV-specific syntax to a custom MythTV protocol that uses XML
> or JSON, and as soon as the services API version starts changing we'll see
> the same issues with it that we had with the custom protocol/syntax.  In
> other words, when we add new features/info/capability to MythTV, supporting
> the old services API protocol/syntax--which doesn't provide the proper
> information--requires exactly the same amount of additional code in the
> backend to "do the right thing" even without all the required information as
> it would have with the old Myth protocol.  And we all know how much code the
> backend has to support old-Myth-protocol clients...
>
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users

While I agree with this, it's still a step forward. Clients should
need to know what version of the services API they are using and adapt
for that. The issue right now is if you want new flashy frontend
features, you have to also upgrade the backend as they aren't
compatible. If you can make a frontend that supports older services
API versions, you get to have different versions of frontends around
the house and don't have to upgrade your stable backend. A frontend
that was written for 0.28 could use a backend that is on 0.25.
Upgrading your MythTV installation is no longer a process that
requires upgrading all systems and possibly the distribution as well.
To do that though, the services API needs to support at least the
basic DVR functionality (which is being worked on). This is precisely
why I think the MythTV frontend should use the services API.

While the services API should grow and change over the releases, I'd
hope that things are added as needed, and changed only when absolutely
necessary. Currently I can ask the services API for a recording based
on filename and I get back a recording. I'm not sure why that would
need to change (unless you move to a recording ID).

Thanks,

Thomas Mashos