[mythtv-users] What if...?

Michael T. Dean mtdean at thirdcontact.com
Mon Sep 24 14:18:42 UTC 2012


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


More information about the mythtv-users mailing list