[mythtv-users] What if...?

Michael T. Dean mtdean at thirdcontact.com
Mon Sep 24 15:47:07 UTC 2012

On 09/24/2012 11:30 AM, Thomas Mashos wrote:
> On Mon, Sep 24, 2012 at 7:18 AM, Michael T. Dean 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...
> 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).

Yes, but in the end it's the same as before...  We /still/ have to write 
code in the backend to support the old protocol requests or this can't 
happen.  XML or JSON over HTTP or []:[] over MythTV socket connection is 
irrelevant to the protocol's forwards compatibility--without backend 
code that understands new /and/ old versions of the protocol (and, even 
more difficult, that comes up with appropriate defaults for missing 
information) there is no forwards compatibility.

You've been able to request a recording by file name using the Myth 
protocol for a long time (forever?) using QUERY_FILETRANSFER , and 
little has changed in its usage, at least in recent memory.  However, 
other things change, which means other parts that are required to get 
the information necessary for successfully issuing that 
QUERY_FILETRANSFER (i.e. getting info on what recordings are available 
and displaying them properly) get broken, which means you can't get to 
the point using that old client for issuing that QUERY_FILETRANSFER...  
(Or, in the future, the same will likely happen with the services API.)

The approach you describe sounds great, but I just don't see us having 
the manpower to code, support, and test(!) all the additional code it 
would require to have current backend support all older versions of any 
protocol (Myth protocol, services API protocol, ...).


More information about the mythtv-users mailing list