Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use BE:PORT/Service/version endpoint rather than GetBackendInfo to get BE's version #250

Open
billmeek opened this issue Feb 4, 2017 · 4 comments
Assignees
Milestone

Comments

@billmeek
Copy link
Contributor

billmeek commented Feb 4, 2017

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:

$ curl -H 'Accept: application/json' mc0:6544/Dvr/version
{"String": "6.3"}
@billmeek billmeek added this to the 3.0.4 milestone Feb 4, 2017
@dmfrey dmfrey modified the milestones: 3.0.5, 3.0.4, 3.1.0 Feb 4, 2017
@billmeek billmeek changed the title Use BE:6544/Service/version endpoint rather than GetBackendInfo to get BE's version Use BE:PORT/Service/version endpoint rather than GetBackendInfo to get BE's version Feb 5, 2017
@dmfrey
Copy link
Contributor

dmfrey commented Feb 7, 2017

@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)

@dmfrey
Copy link
Contributor

dmfrey commented Feb 11, 2017

@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?

@billmeek
Copy link
Contributor Author

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.

@billmeek
Copy link
Contributor Author

Looks like Arch uses atypical versions:
https://lists.gt.net/mythtv/users/607585#607585
Specifically:
MythTV Version : 3543e74
MythTV Branch : tag: v0.28

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants