Mailing List Archive

Services API for ChannelServices / Video Source
Hi,

I've recently added two parameters to the Video Source page of
mythtv-setup, bouquet_id and region_id. These are used to get the
channel numbers for Freesat and BSkyB on the Astra-2 28.2E satellite.

I am now about to add these parameters to functions in
channelservices.cpp/h such as AddVideoSource which are, as I
understand it, part of what is called the Services API. This does
compile cleanly but I am not aware of which other code or applications
does actually use this.

Are there applications I can test with or other steps I should take or
shall I just commit this to master and wait what happens?

Groetjes,
Klaas.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On 10/31/19 6:26 AM, Klaas de Waal wrote:
> Hi,
>
> I've recently added two parameters to the Video Source page of
> mythtv-setup, bouquet_id and region_id. These are used to get the
> channel numbers for Freesat and BSkyB on the Astra-2 28.2E satellite.
>
> I am now about to add these parameters to functions in
> channelservices.cpp/h such as AddVideoSource which are, as I
> understand it, part of what is called the Services API. This does
> compile cleanly but I am not aware of which other code or applications
> does actually use this.
>
> Are there applications I can test with or other steps I should take or
> shall I just commit this to master and wait what happens?
>
> Groetjes,
> Klaas.

Hi Klaas,

If you'd like me to run some test, just let me know when you push.

Otherwise, if it helps, I just added a parameter to an existing endpoint here:

git log --author Bill --patch -1

5 files changed:

libs/libmythservicecontracts/services/channelServices.h
libs/libmythtv/channelutil.{cpp,h}
programs/mythbackend/services/channel.{cpp,h}

For testing, curl works OK. Sounds like the above adds/changes data,
which means a POST is required. Here's an old example of the format:

curl \
--data ChanID=1021 \
...
--data XMLTVID=20454 \
backendNameOrIP:6544/Channel/UpdateDBChannel

Or, you can use the Python bindings for the Services API similar to this:

#!/usr/bin/python
"""Simple POST example"""

from __future__ import print_function
import os.path
import sys
from MythTV.services_api import send as api


def main():
"""Check arguments and call send() with a POST"""

try:
behost = sys.argv[1]
dbhost = sys.argv[2]
dbuser = sys.argv[3]
dbpswd = sys.argv[4]
except IndexError:
sys.exit('\nUsage: {} backend_host db_host db_user db_password'
.format(os.path.basename(sys.argv[0])))

postdata = {'HostName': dbhost, 'UserName': dbuser, 'Password': dbpswd}

backend = api.Send(host=behost)
backend.send(endpoint='Myth/TestDBSettings', postdata=postdata,
opts={'wrmi': True})


if __name__ == '__main__':
main()

--
Bill
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On Thu, 31 Oct 2019 at 15:07, Bill Meek <keemllib@gmail.com> wrote:
>
> On 10/31/19 6:26 AM, Klaas de Waal wrote:
> > Hi,
> >
> > I've recently added two parameters to the Video Source page of
> > mythtv-setup, bouquet_id and region_id. These are used to get the
> > channel numbers for Freesat and BSkyB on the Astra-2 28.2E satellite.
> >
> > I am now about to add these parameters to functions in
> > channelservices.cpp/h such as AddVideoSource which are, as I
> > understand it, part of what is called the Services API. This does
> > compile cleanly but I am not aware of which other code or applications
> > does actually use this.
> >
> > Are there applications I can test with or other steps I should take or
> > shall I just commit this to master and wait what happens?
> >
> > Groetjes,
> > Klaas.
>
> Hi Klaas,
>
> If you'd like me to run some test, just let me know when you push.
>
> Otherwise, if it helps, I just added a parameter to an existing endpoint here:
>
> git log --author Bill --patch -1
>
> 5 files changed:
>
> libs/libmythservicecontracts/services/channelServices.h
> libs/libmythtv/channelutil.{cpp,h}
> programs/mythbackend/services/channel.{cpp,h}
>
> For testing, curl works OK. Sounds like the above adds/changes data,
> which means a POST is required. Here's an old example of the format:
>
> curl \
> --data ChanID=1021 \
> ...
> --data XMLTVID=20454 \
> backendNameOrIP:6544/Channel/UpdateDBChannel
>
> Or, you can use the Python bindings for the Services API similar to this:
>
> #!/usr/bin/python
> """Simple POST example"""
>
> from __future__ import print_function
> import os.path
> import sys
> from MythTV.services_api import send as api
>
>
> def main():
> """Check arguments and call send() with a POST"""
>
> try:
> behost = sys.argv[1]
> dbhost = sys.argv[2]
> dbuser = sys.argv[3]
> dbpswd = sys.argv[4]
> except IndexError:
> sys.exit('\nUsage: {} backend_host db_host db_user db_password'
> .format(os.path.basename(sys.argv[0])))
>
> postdata = {'HostName': dbhost, 'UserName': dbuser, 'Password': dbpswd}
>
> backend = api.Send(host=behost)
> backend.send(endpoint='Myth/TestDBSettings', postdata=postdata,
> opts={'wrmi': True})
>
>
> if __name__ == '__main__':
> main()
>
> --
> Bill
> _______________________________________________

Hi Bill,

I have committed support for the bouquet ID and the region ID in the
services API but not yet tested anything. I followed what was done
for the dvb_nit_id and I think the C++ code is correct and complete. I
made some changes to the Javascript code but I am not sure what else
needs to be done there or what needs to be done in other non-C++ parts
of the code. I do appreciate it very much if you would have a look at
it.

For the people who read this and feel tempted to play with this, the
code does need the fields bouquet_id and region_id and one way to test
it is to add these fields manually to database table videosource; SQL
commands given in dbcheck.cpp. Changing the schema version to 1351 in
mythversion.h does this and also activates the mythtv-setup gui for
these fields but this should only be done on a discardable database.


Groetjes,
Klaas.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On Thu, Oct 31, 2019 at 9:43 PM Klaas de Waal <klaas.de.waal@gmail.com> wrote:

> I have committed support for the bouquet ID and the region ID in the
> services API but not yet tested anything.

I would hope the documentation will be updated.

And changes to the Services API brings up the
regular repeated issue of versioning of the services
API invokations when new required fields are added
in order to support backwards compatibility for existing
users of the API. if the project wants to use the model
of the API is not stable (and get over it), then versioning
does not matter, but that also means the Services API
should not be used outside of project provided scripts
because they will break whenever in various ways.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On Friday, 1 November 2019 07:12:07 GMT Gary Buhrmaster wrote:
> On Thu, Oct 31, 2019 at 9:43 PM Klaas de Waal <klaas.de.waal@gmail.com>
wrote:
> > I have committed support for the bouquet ID and the region ID in the
> > services API but not yet tested anything.
>
> I would hope the documentation will be updated.
>
> And changes to the Services API brings up the
> regular repeated issue of versioning of the services
> API invokations when new required fields are added
> in order to support backwards compatibility for existing
> users of the API. if the project wants to use the model
> of the API is not stable (and get over it), then versioning
> does not matter, but that also means the Services API
> should not be used outside of project provided scripts
> because they will break whenever in various ways.

The services API was intended to retain backwards compatibility at all times,
although in the early days some breaking changes were necessary to bring the
API endpoints into line with each other. It has repeatedly been stated that
the Services API is the true public interface to the system and that third
party software using the internal protocol should switch to it for this very
reason.

As such changes which break compatibility would require a new endpoint to be
created. Usually this is avoidable, especially when we're just talking about
new parameters being added, since these can be made optional with sane default
values.

A proper versioning system, where the client specifies the version they
understand and requests are handled accordingly would be good to have.

--
Stuart Morgan





_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On 31/10/2019 21:42, Klaas de Waal wrote:
> On Thu, 31 Oct 2019 at 15:07, Bill Meek <keemllib@gmail.com> wrote:
>> On 10/31/19 6:26 AM, Klaas de Waal wrote:
>>> Hi,
>>>
>>> I've recently added two parameters to the Video Source page of
>>> mythtv-setup, bouquet_id and region_id. These are used to get the
>>> channel numbers for Freesat and BSkyB on the Astra-2 28.2E satellite.
>>>
>>> I am now about to add these parameters to functions in
>>> channelservices.cpp/h such as AddVideoSource which are, as I
>>> understand it, part of what is called the Services API. This does
>>> compile cleanly but I am not aware of which other code or applications
>>> does actually use this.
>>>
>>> Are there applications I can test with or other steps I should take or
>>> shall I just commit this to master and wait what happens?
>>>
>>> Groetjes,
>>> Klaas.
>> Hi Klaas,
>>
>> If you'd like me to run some test, just let me know when you push.
>>
>> Otherwise, if it helps, I just added a parameter to an existing endpoint here:
>>
>> git log --author Bill --patch -1
>>
>> 5 files changed:
>>
>> libs/libmythservicecontracts/services/channelServices.h
>> libs/libmythtv/channelutil.{cpp,h}
>> programs/mythbackend/services/channel.{cpp,h}
>>
>> For testing, curl works OK. Sounds like the above adds/changes data,
>> which means a POST is required. Here's an old example of the format:
>>
>> curl \
>> --data ChanID=1021 \
>> ...
>> --data XMLTVID=20454 \
>> backendNameOrIP:6544/Channel/UpdateDBChannel
>>
>> Or, you can use the Python bindings for the Services API similar to this:
>>
>> #!/usr/bin/python
>> """Simple POST example"""
>>
>> from __future__ import print_function
>> import os.path
>> import sys
>> from MythTV.services_api import send as api
>>
>>
>> def main():
>> """Check arguments and call send() with a POST"""
>>
>> try:
>> behost = sys.argv[1]
>> dbhost = sys.argv[2]
>> dbuser = sys.argv[3]
>> dbpswd = sys.argv[4]
>> except IndexError:
>> sys.exit('\nUsage: {} backend_host db_host db_user db_password'
>> .format(os.path.basename(sys.argv[0])))
>>
>> postdata = {'HostName': dbhost, 'UserName': dbuser, 'Password': dbpswd}
>>
>> backend = api.Send(host=behost)
>> backend.send(endpoint='Myth/TestDBSettings', postdata=postdata,
>> opts={'wrmi': True})
>>
>>
>> if __name__ == '__main__':
>> main()
>>
>> --
>> Bill
>> _______________________________________________
> Hi Bill,
>
> I have committed support for the bouquet ID and the region ID in the
> services API but not yet tested anything. I followed what was done
> for the dvb_nit_id and I think the C++ code is correct and complete. I
> made some changes to the Javascript code but I am not sure what else
> needs to be done there or what needs to be done in other non-C++ parts
> of the code. I do appreciate it very much if you would have a look at
> it.
>
> For the people who read this and feel tempted to play with this, the
> code does need the fields bouquet_id and region_id and one way to test
> it is to add these fields manually to database table videosource; SQL
> commands given in dbcheck.cpp. Changing the schema version to 1351 in
> mythversion.h does this and also activates the mythtv-setup gui for
> these fields but this should only be done on a discardable database.
>
>
> Groetjes,
> Klaas.
> _______________________________________________

Just for information.

I quickly tested current Kodi (Leia 18.4) with kodi-pvr-mythtv addon
(5.10.13) with the updated database (1351) and Services API everything
still works,

Normally with a Services API/schema change I would expect an update to
MYTH_PROTO_VERSION (currently 91) and MYTH_PROTO_TOKEN (currently BuzzOff).

Updating these means a change to kodi-pvr-mythtv addon (it uses
MYTH_PROTO_VERSION to decide how to process Services API calls).


Mike




_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On Fri, Nov 01, 2019 at 08:54:18AM +0000, Stuart Morgan wrote:
> On Friday, 1 November 2019 07:12:07 GMT Gary Buhrmaster wrote:
> > On Thu, Oct 31, 2019 at 9:43 PM Klaas de Waal <klaas.de.waal@gmail.com>
> wrote:
> > > I have committed support for the bouquet ID and the region ID in the
> > > services API but not yet tested anything.
> >
> > I would hope the documentation will be updated.
> >
> > And changes to the Services API brings up the
> > regular repeated issue of versioning of the services
> > API invokations when new required fields are added
> > in order to support backwards compatibility for existing
> > users of the API. if the project wants to use the model
> > of the API is not stable (and get over it), then versioning
> > does not matter, but that also means the Services API
> > should not be used outside of project provided scripts
> > because they will break whenever in various ways.
>
> The services API was intended to retain backwards compatibility at all times,
> although in the early days some breaking changes were necessary to bring the
> API endpoints into line with each other. It has repeatedly been stated that
> the Services API is the true public interface to the system and that third
> party software using the internal protocol should switch to it for this very
> reason.
>
> As such changes which break compatibility would require a new endpoint to be
> created. Usually this is avoidable, especially when we're just talking about
> new parameters being added, since these can be made optional with sane default
> values.
>
> A proper versioning system, where the client specifies the version they
> understand and requests are handled accordingly would be good to have.

I am nearly, totally unfamiliar with the inner workings of the
services code or I would have tried fixing some of the issues. I see
things we need to be able to handle multiple versions of endpoints and
advertise which ones we support.

Unless someone knows how to do that, perhaps we could get by using an
ugly, brute force technique of including a version indication in the
endpoint name itself. For exaplle, when the UpdateWidget endpoint
needs an incompatible change, add a new UpdateWidget2 endpoint and
change the old, AddWidget endpoint to either do the right thing of
fail gracefully.

Also, another failing of the current API is the inability to pass an
"unspecified" indication to the endpoint. In some cases, it's
possible to use an empty string or numeric 0 but that doesn't work
everywhere where such values are valid. It might be nice if the API
layer could pass something like QVariants which could be tested to see
if they are of the expected type or are "NULL".

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On Fri, Nov 01, 2019 at 11:15:57AM +0000, Mike Bibbings wrote:
> On 31/10/2019 21:42, Klaas de Waal wrote:
> > Hi Bill,
> >
> > I have committed support for the bouquet ID and the region ID in the
> > services API but not yet tested anything. I followed what was done
> > for the dvb_nit_id and I think the C++ code is correct and complete. I
> > made some changes to the Javascript code but I am not sure what else
> > needs to be done there or what needs to be done in other non-C++ parts
> > of the code. I do appreciate it very much if you would have a look at
> > it.
> >
> > For the people who read this and feel tempted to play with this, the
> > code does need the fields bouquet_id and region_id and one way to test
> > it is to add these fields manually to database table videosource; SQL
> > commands given in dbcheck.cpp. Changing the schema version to 1351 in
> > mythversion.h does this and also activates the mythtv-setup gui for
> > these fields but this should only be done on a discardable database.
> >
> >
> > Groetjes,
> > Klaas.
> > _______________________________________________
>
> Just for information.
>
> I quickly tested current Kodi (Leia 18.4) with kodi-pvr-mythtv addon
> (5.10.13) with the updated database (1351) and Services API everything still
> works,

That's not surprising. I don't believe Kodi supports adding or
editing anything in that area of MythTV. Rather, it's probably left
for the user to configure sort of stuff in MythTV directly.

> Normally with a Services API/schema change I would expect an update to
> MYTH_PROTO_VERSION (currently 91) and MYTH_PROTO_TOKEN (currently BuzzOff).
>
> Updating these means a change to kodi-pvr-mythtv addon (it uses
> MYTH_PROTO_VERSION to decide how to process Services API calls).

The database schema, protocol and services API are closely related and
a change in one area often ripples into the others but that doesn't
always have to be the case.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On 01/11/2019 14:56, David Engel wrote:
> On Fri, Nov 01, 2019 at 11:15:57AM +0000, Mike Bibbings wrote:
>> On 31/10/2019 21:42, Klaas de Waal wrote:
>>> Hi Bill,
>>>
>>> I have committed support for the bouquet ID and the region ID in the
>>> services API but not yet tested anything. I followed what was done
>>> for the dvb_nit_id and I think the C++ code is correct and complete. I
>>> made some changes to the Javascript code but I am not sure what else
>>> needs to be done there or what needs to be done in other non-C++ parts
>>> of the code. I do appreciate it very much if you would have a look at
>>> it.
>>>
>>> For the people who read this and feel tempted to play with this, the
>>> code does need the fields bouquet_id and region_id and one way to test
>>> it is to add these fields manually to database table videosource; SQL
>>> commands given in dbcheck.cpp. Changing the schema version to 1351 in
>>> mythversion.h does this and also activates the mythtv-setup gui for
>>> these fields but this should only be done on a discardable database.
>>>
>>>
>>> Groetjes,
>>> Klaas.
>>> _______________________________________________
>> Just for information.
>>
>> I quickly tested current Kodi (Leia 18.4) with kodi-pvr-mythtv addon
>> (5.10.13) with the updated database (1351) and Services API everything still
>> works,
> That's not surprising. I don't believe Kodi supports adding or
> editing anything in that area of MythTV. Rather, it's probably left
> for the user to configure sort of stuff in MythTV directly.
>
>> Normally with a Services API/schema change I would expect an update to
>> MYTH_PROTO_VERSION (currently 91) and MYTH_PROTO_TOKEN (currently BuzzOff).
>>
>> Updating these means a change to kodi-pvr-mythtv addon (it uses
>> MYTH_PROTO_VERSION to decide how to process Services API calls).
> The database schema, protocol and services API are closely related and
> a change in one area often ripples into the others but that doesn't
> always have to be the case.
>
> David


Yes, Kodi generally assumes that user has already setup MythTV, there
are some exceptions, for example, kodi-pvr-mythtv allows Recording
schedules (called Timers in Kodi) to be manipulated (delete, add,
modify) via POST Service API calls.

The handling of Recording schedules in kodi-pvr-mythtv does not have the
same flexibility as a MythTV frontend or mythweb.


Mike


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On Fri, Nov 1, 2019 at 2:49 PM David Engel <david@istwok.net> wrote:
>
> On Fri, Nov 01, 2019 at 08:54:18AM +0000, Stuart Morgan wrote:

> > The services API was intended to retain backwards compatibility at all times,

Thanks for confirming backwards compatibility is the
intended goal. My concern was that it appeared
that in this case (based on the words in the email;
I have not personally tested) that this was not
properly implemented in this case, with new
(required) parameters which would (especially in
the case of updates) reset values not provided
by existing callers. If my understanding in not
correct, my apologies.

> Also, another failing of the current API is the inability to pass an
> "unspecified" indication to the endpoint.

I keep running into this one and the one where providing
a JSON None does not result in a DB NULL value (where
the value NULL is dealt with differently in the code base
(than something like a 0 or empty string) so one must get
a NULL in there, but at least in the cases I care about,
there was no way to do so).

As for backward compatibility, for the Update methods,
(I don't know how easy it is to implement), I would
prefer that one should only update the provided values,
not a complete row replacement (could be done by very
selective DB updates of the provided entities, or
retrieving the existing values, merging the provided
input, and then doing the update). I have had to jump
through some hoops to do the equivalent (and even
have a couple of cases of version specific checks for
what to do and how to do it for some changes in the
services API for some more obscure use cases).

Anyway, thanks for accepting the input (even though
it appears I have opened the can of worms).
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On 10/31/19 4:42 PM, Klaas de Waal wrote:

...

> I have committed support for the bouquet ID and the region ID in the
> services API but not yet tested anything. I followed what was done
> for the dvb_nit_id and I think the C++ code is correct and complete. I
> made some changes to the Javascript code but I am not sure what else
> needs to be done there or what needs to be done in other non-C++ parts
> of the code. I do appreciate it very much if you would have a look at
> it.

...

Looks good. BouquetId and RegionId default to 0 (so they aren't required.)
The output of GetVideoSource[List] changes, that could cause users of those
endpoints problems if they don't handle unexpected parameters.

Users should be looking at BE:6544/<Service name>/version, more on
that below.

I've never used/tested the Add/Update VideoSource endpoints, but noticed
that when Update is used, the return is true even if a non-existing SourceId
is used. Not sure how to make the SQL return false and has nothing to do
with these additions.

Otherwise, Add returns the SourceId as expected. Add and Update change the
DB as expected.

I believe the only change required is to bump the minor version. Which I
forgot to do after adding the OnlyTunable parameter to Channel/GetChannelInfoList.

I'll do that unless someone disagrees (same for the new Myth/DelayShutdown endpoint.)

diff --git a/mythtv/libs/libmythservicecontracts/services/channelServices.h b/mythtv/libs/libmythservicecontracts/services/channelServices.h
index 6d194b3a0d..8a8df6bb13 100644
--- a/mythtv/libs/libmythservicecontracts/services/channelServices.h
+++ b/mythtv/libs/libmythservicecontracts/services/channelServices.h
@@ -41,7 +41,7 @@
class SERVICE_PUBLIC ChannelServices : public Service
{
Q_OBJECT
- Q_CLASSINFO( "version" , "1.6" );
+ Q_CLASSINFO( "version" , "1.7" );
Q_CLASSINFO( "AddDBChannel_Method", "POST" )
Q_CLASSINFO( "UpdateDBChannel_Method", "POST" )
Q_CLASSINFO( "RemoveDBChannel_Method", "POST" )
diff --git a/mythtv/libs/libmythservicecontracts/services/mythServices.h b/mythtv/libs/libmythservicecontracts/services/mythServices.h
index b4fc7834d4..29696bd44f 100644
--- a/mythtv/libs/libmythservicecontracts/services/mythServices.h
+++ b/mythtv/libs/libmythservicecontracts/services/mythServices.h
@@ -44,7 +44,7 @@
class SERVICE_PUBLIC MythServices : public Service //, public QScriptable ???
{
Q_OBJECT
- Q_CLASSINFO( "version" , "5.1" );
+ Q_CLASSINFO( "version" , "5.2" );
Q_CLASSINFO( "AddStorageGroupDir_Method", "POST" )
Q_CLASSINFO( "RemoveStorageGroupDir_Method", "POST" )
Q_CLASSINFO( "PutSetting_Method", "POST" )

--
Bill
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On Fri, Nov 1, 2019 at 4:06 PM Gary Buhrmaster
<gary.buhrmaster@gmail.com> wrote:
>
> On Fri, Nov 1, 2019 at 2:49 PM David Engel <david@istwok.net> wrote:

> > Also, another failing of the current API is the inability to pass an
> > "unspecified" indication to the endpoint.

Oh, another nit (and my recollection is that it
occurs with a few endpoints) is the returned
name is different than the name one must
provide for add/updates (sometimes it is
just capitalization (is it xxxID or xxxId?), and
in some cases it is slightly different name
entirely (ChannelNumber input vs ChanNum
returned?) which requires transformations
of the names by the client apps. Fortunately,
I don't think any have been recently introduced
(so as long as I remember the old ones I don't
need to learn anything new).
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On Fri, Nov 01, 2019 at 04:06:55PM +0000, Gary Buhrmaster wrote:
> On Fri, Nov 1, 2019 at 2:49 PM David Engel <david@istwok.net> wrote:
> >
> > On Fri, Nov 01, 2019 at 08:54:18AM +0000, Stuart Morgan wrote:
>
> > > The services API was intended to retain backwards compatibility at all times,
>
> Thanks for confirming backwards compatibility is the
> intended goal. My concern was that it appeared
> that in this case (based on the words in the email;
> I have not personally tested) that this was not
> properly implemented in this case, with new
> (required) parameters which would (especially in
> the case of updates) reset values not provided
> by existing callers. If my understanding in not
> correct, my apologies.
>
> > Also, another failing of the current API is the inability to pass an
> > "unspecified" indication to the endpoint.
>
> I keep running into this one and the one where providing
> a JSON None does not result in a DB NULL value (where
> the value NULL is dealt with differently in the code base
> (than something like a 0 or empty string) so one must get
> a NULL in there, but at least in the cases I care about,
> there was no way to do so).
>
> As for backward compatibility, for the Update methods,
> (I don't know how easy it is to implement), I would
> prefer that one should only update the provided values,
> not a complete row replacement (could be done by very
> selective DB updates of the provided entities, or
> retrieving the existing values, merging the provided
> input, and then doing the update). I have had to jump
> through some hoops to do the equivalent (and even
> have a couple of cases of version specific checks for
> what to do and how to do it for some changes in the
> services API for some more obscure use cases).

<brainfart hopefulesomewilltrythis="true">

I wonder if the core services code could be coerced, or bludgeoned,
into doing a fule read/update/write. For example, when UpdateFoo() is
called, first call GetFoo() to get the "template" for this update,
update the template with the new valuses that are present and then
sanity check and save the merged result if valid.

One like problem with this would be the inconsisten input/output
naming you mentioned in another email. Fixing that could go hand in
hand with this.

</brainfart>

David

>
> Anyway, thanks for accepting the input (even though
> it appears I have opened the can of worms).
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API for ChannelServices / Video Source [ In reply to ]
On Fri, 1 Nov 2019 09:49:05 -0500
David Engel <david@istwok.net> wrote:

> Also, another failing of the current API is the inability to pass an
> "unspecified" indication to the endpoint. In some cases, it's
> possible to use an empty string or numeric 0 but that doesn't work
> everywhere where such values are valid. It might be nice if the API
> layer could pass something like QVariants which could be tested to see
> if they are of the expected type or are "NULL".
>

That would be a big job, obscuring the interfaces and creating a endless
list of "this service doesn't work like it used to" bugs. It may also
break the wsdl.

The server encapsulates the type conversions to make the service
handlers more robust and simple to maintain.

Most endpoints happily use default values to determine unspecified
parameters. The few that can't can use the solution in:
https://github.com/MythTV/mythtv/commit/681a33766aeed02f63295a8a613c5e70cb5b714d

as used in UpdateVideoMetaData:
https://github.com/MythTV/mythtv/blob/aac69a9f9a41bd32aedf7de4b7f2dae141a234b4/mythtv/programs/mythbackend/services/video.cpp#L503
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org