Open billmeek opened 7 years ago
@billmeek I think we need to figure out how/where we are going to use this information. Aside from tests in the troubleshooter, it could really be used to differentiate functionality based on the backend you are connecting to. Is there anywhere that breaks down the individual API versions with the methods/signatures of the implemented endpoints?
Where would we present this info in the app. I was thinking we could see if we could use the bottom portion of the navigation drawer. Maybe even get rid of the About dialog and move most of that down there too (if its possible)
@billmeek would it be possible to refactor /Myth/GetBackendInfo
to include the versions of each of the MythTV Services endpoints? Also, could this be backported? I am hesitant to call all these services all the time when one service call could suffice to supply all the data.
I would recommend adding a ServiceInfo object to the BackendInfo object so that it would match something similar to the following:
<BackendInfo>
<Build />
<Env />
<Log />
<Service>
<Myth>9.9</Myth>
<Dvr>9.9</Dvr>
<Content>9.9</Content>
<Video>9.9</Video>
...
</Service>
</BackendInfo>
I am also thinking it would be helpful for Build object to contain a normalized version of mythtv. So it would just contain 0.27, 0.28, 0.29, etc. Whichever is appropriate for the version of the backend running.
Thoughts?
Great ideas. I'm looking into the GetBackendInfo one. No joy yet. I know where it's set, just not how to pull the value into the Myth service.
If possible, I think I'd add a parameter, e.g. GetServiceVersions to the endpoint, so that any existing users wouldn't see a change to the response. That's how I'd backport it, but haven't looked at 0.27 yet.
It wouldn't be necessary to call eachService/version all the time, just at app startup. Same for an enhanced GetBackendVersion. I thought storing the values in memory, as opposed to settings, would suffice.
The normalized version one looks tougher, not that it couldn't be done manually, but that the existing is generated automatically. It's just that a few folks corrupt it.
Interesting that I've gotten no replies on G+ from app users that can see the problem.
Looks like Arch uses atypical versions: https://lists.gt.net/mythtv/users/607585#607585 Specifically: MythTV Version : 3543e74 MythTV Branch : tag: v0.28
As discussed in #246, some distributions and or users aren't using the 'normal' MythTV version string e.g. v29-pre-303-g37c172e-dirty. This makes the existing tests unreliable.
Considering that there is no known evidence of users changing the Service/version endpoint's value, it seems to be a more reliable way to be sure the app will be compatible with the Services API.
Example: