[mythtv-users] What if...?
thomas at mashos.com
Mon Sep 24 15:57:49 UTC 2012
On Mon, Sep 24, 2012 at 8:47 AM, Michael T. Dean
<mtdean at thirdcontact.com> 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, ...).
> mythtv-users mailing list
> mythtv-users at mythtv.org
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
More information about the mythtv-users