[mythtv-users] What if...?
Michael T. Dean
mtdean at thirdcontact.com
Mon Sep 24 16:30:22 UTC 2012
On 09/24/2012 11:57 AM, Thomas Mashos wrote:
> On Mon, Sep 24, 2012 at 8:47 AM, Michael T. Dean wrote:
>> 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.
>>>>> 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
>>>> 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
>>>> 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
>>>> support such behavior must build in support for the feature by knowing
>>>> 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
>>>> an old version of MythTV's services API will work with all future
>>>> of MythTV services API)--so clients will have to provide their own
>>>> compatibility (clients will need to figure out what services API version
>>>> 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
>>>> 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
>>>> API is doing is changing our custom MythTV protocol from one that uses
>>>> text in a MythTV-specific syntax to a custom MythTV protocol that uses
>>>> or JSON, and as soon as the services API version starts changing we'll
>>>> 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,
>>>> 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
>>>> it would have with the old Myth protocol. And we all know how much code
>>>> 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, ...).
> Mike, I think you are misunderstanding my request. Have the backend
> only support a single services API version (as it does now) and have
> the frontend "fall back" to whatever feature set that version supports
> (IDK, that is probably what 3rd party frontends did without the
> services API). My understanding for the services API was that it is
> better able to support 3rd party frontends. The backend doesn't need
> to support any old services API version (as forwards compatible would
> imply that the frontend is the newer version, not the backend), just
> the frontend being able to talk to older versions of the backend.
> (which isn't on you for 3rd party frontends, but if the official
> mythtv frontend could do that too it would be great).
> Basically I think the wish is for people to get a nice stable backend
> in place and then just need to upgrade their frontends for new flashy
Right. Forwards compatible means that a program written for an old
version continues to work with newer versions. I.e. it is compatible
with new versions as we move forward in the timeline.
Backwards compatible means that a program written for an new version
also works with old versions.
We can either have a backend that allows forwards-compatible clients by
including support for all old versions of the protocol (and appropriate
defaults for missing information and ...) and clients wouldn't need to
be updated with changes to MythTV.
Alternatively, every single client can be written to be backwards
compatible by including support for older versions of the protocol and
either falling back to reduced functionality or using appropriate
defaults for missing information/...
Or, we can just require same-versioned clients/server. This is the
approach we had taken with the Myth protocol--i.e. we support one
version/same version everywhere and don't try to write new code to
support mixed protocol versions. This is also the approach I would
expect us to take even if mythfrontend were changed to use the services
API--primarily because writing, testing, and maintaining the additional
code to support mixed-versioned systems is a lot of work, and we don't
have a lot of workers to do that work.
Some 3rd party clients, however, tried to take the
backwards-compatibility approach, with varying degrees of success (and
varying degrees of danger to the user's MythTV data/system).
But in the end, someone has to write, test, and maintain additional code.
I may be wrong in my expectations, and someone may decide to take on the
challenge, though. Only the future will tell.
My main point, though, is to ensure that no one thinks that XML or JSON
(or even the services API, itself) provide some magic compatibility for
us. It's still up to some developer to write (and test and maintain)
code, somewhere, to provide that compatibility.
More information about the mythtv-users