v32 api changes via port 6744

Post Reply
PhilB
Senior
Posts: 403
Joined: Sun May 11, 2014 6:23 pm
Great Britain

v32 api changes via port 6744

Post by PhilB »

The new API interface in v32 via port 6744 is giving different results to the old.

Most calls have tags around items eg for GetChannelInfoList the info for each channel was wrapped between
<ChannelInfo> and </ChannelInfo>.


With port 6744 the tags are:
<ChannelInfo version="2.2"> and </ChannelInfo>

Is this likely to be a permanent change?
Phil
User avatar
paulh
Developer
Posts: 909
Joined: Thu Feb 06, 2014 6:09 pm
Great Britain

Re: v32 api changes via port 6744

Post by paulh »

There are some subtle differences like the extra version attribute between the old and new API but any XML parser should still be able to parse it without problems. The actual names of the elements are the same so it shouldn't in theory be causing any problems.

What sort of problems are you having?
PhilB
Senior
Posts: 403
Joined: Sun May 11, 2014 6:23 pm
Great Britain

Re: v32 api changes via port 6744

Post by PhilB »

Problems are with my rather simple parsing code which I should have plenty of time to fix!
Thanks
Phil
PhilB
Senior
Posts: 403
Joined: Sun May 11, 2014 6:23 pm
Great Britain

Re: v32 api changes via port 6744

Post by PhilB »

In addition to the above, which may require changes by those with DIY parsers, I have found a few other changes:

1. Some years ago I started using the API call /Channel/VideoSourceList. That worked with 0.27 up to v32 but fails with
v32 via port 6744. It's my user error - it should of course be /Channel/GetVideoSourceList.
I only document it here in case others are using it.

2. the treatment of null parameters has changed.
I had assumed that null parameters would be returned as <key></key> or <key/> and that missing parameters indicated an API user
programming error - "That's an invalid key - fix your error".
However, I now find that port 6544 misses some out and port 6744 misses out even more.
This shows up with but may not be limited to Dvr/GetRecordedList. I first found missing 'CallSign' values but it also affects a dozen or so more.

I must change my thinking (and routines) to assume null in these cases.
Is this a bug or a feature? I'm inclined to say bug but finding and eliminating them all might be a huge task.

3. There are changes in some calls as indicated by wsdl calls.
Dvr/AddDontRecordSchedule
Dvr/AllowReRecord
Dvr/ReactivateRecording
Dvr/RescheduleRecordings
Dvr/StopRecording
Dvr/UnDeleteRecording
are all (rightly) now POST rather than GET

Dvr/GetLastPlayPos
Dvr/SetLastPlayPos
Myth/SetConnectionInfo
Video/GetLastPlayPos
Video/SetLastPlayPos
are all new.

I have put up a new wiki wsdl page with the new parameters.

I am having to put in tweaks to three of my routines - scan_database.pm, chedit2.pl and checkfilm.pl (see UK forum) and will
update them once I have finished testing.

Phil
User avatar
bill6502
Developer
Posts: 2299
Joined: Fri Feb 07, 2014 5:28 pm
United States of America

Re: v32 api changes via port 6744

Post by bill6502 »

Thanks for that Phil. New development will be limited to the V2 API, as you spotted with the last 5 endpoints above.
PhilB
Senior
Posts: 403
Joined: Sun May 11, 2014 6:23 pm
Great Britain

Re: v32 api changes via port 6744

Post by PhilB »

An update:

I have updated the module scan_database.pm published in Perl API Examples to accept the more complex xml pumped out by the API interface.

I had to put tweaks into channel editor (chedit2.pl) and the code for checking split films (checkfilm.pl - see UK forum)
to correct an invalid API call (VideoSourceList not GetVideoSourceList) which amazingly worked with port v6544.

The API documentation generator reading wsdl and generating wiki text is unchanged but will need scan_database updating.

<tinhat>on</tinhat>

I hesitate here but feel I must express a personal view and make a request:

I have only seen valid xml generated by the new API interface but I have seen many variants of the way data is displayed.
That is very unfortunate because the joy of the old interface is that you can very easily extract information with a bit of pipe, curl, sed and grep, or a 'get' followed by a bit of SIMPLE regex in perl or the python equivalent. It is so powerful. You cannot do that with the new interface and I think that a great pity.

Whereas previously you could rely on a consistent format of <key>value</key> for almost everything you now also have to consider <key/>,
<key xsi:nil="true"/> or simply ... an omitted key/value!. Also separators like <sep attribute="value"> rather than just <sep> but hopefully more ghastly variants involving attributes will not emerge.

I stress that all of these variants are perfectly valid xml - it's just not consistent enough to allow quick application development and I think it will deter use of the API. I presume that some standard package is used to generate xml from mysql but could it be easily configured to avoid attributes and to only put out values in the form <key>value</key> ?

Discussion invited!
<tinhat>off</tinhat>

Phil
User avatar
paulh
Developer
Posts: 909
Joined: Thu Feb 06, 2014 6:09 pm
Great Britain

Re: v32 api changes via port 6744

Post by paulh »

I agree with most of what you say there should be more consistency where possible. We did try hard to maintain compatibility with the old API it was something I was quite adamant about since I know first hand that API changes can be a big problem especially if you want to keep backward compatibility.
Even worse is if they aren't documented anywhere.

I don't think we really now why Mark added the version="x.x" attribute or the xsi:nil="true" unfortunately he is know longer around to ask and doesn't respond to emails etc. When I asked the other devs the question the reply was what I said originally any XML parser should be able to parse it without problems. Yes if you are using bash commands to parse it can be more difficult.

We don't use any external tools or libraries to serialise the XML or the JSON it's all custom code so the output could be tweaked if necessary.

A quick scan of the git log and git blame I couldn't find any changes to GetVideoSourceList as far as I can tell it's always been called that since it was added by Robert 11 years ago to the V1 API and the V2 code is mostly just a copy and paste of the old code so not sure what you mean there.
PhilB
Senior
Posts: 403
Joined: Sun May 11, 2014 6:23 pm
Great Britain

Re: v32 api changes via port 6744

Post by PhilB »

Thanks Paul.
I was perhaps not very clear about the GetVideoSourceList. As far as I know it always has been that. Back in about 2014 (version 0.17) I made a silly typo and made an API call to VideoSourceList. That was incorrect but it worked and my error lurked undetected through later versions of Mythtv until v32 port 6547 quite correctly rejected it.
Phil
User avatar
bill6502
Developer
Posts: 2299
Joined: Fri Feb 07, 2014 5:28 pm
United States of America

Re: v32 api changes via port 6744

Post by bill6502 »

Interesting, Myth/HostName works, as to some other endpoints that expect Get...
I didn't test all Get... types.
Post Reply