<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 10, 2015 at 8:40 AM Michael T. Dean <<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/10/2015 08:33 AM, Michael T. Dean wrote:<br>
> On 12/10/2015 08:11 AM, Philip Brady wrote:<br>
>> 4.  Python bindings.   I do not speak Python but it appears to be<br>
>> documented and has a number of published applications using it.  What<br>
>> is the long term future for those applications?  Are the bindings and<br>
>> the underlying code going to be maintained well into the future so<br>
>> these useful utilities still work or is it possible to create a<br>
>> 'shim' piece of code to take binding calls and turn them into API calls?<br>
><br>
> Ideally (meaning the plan is, assuming someone makes time to do it)<br>
> the bindings (Perl, Python, and future to-be-created ones) will be<br>
> changed to make calls using the service API, as any 3rd party<br>
> application should.  Then, the bindings just become building<br>
> blocks/convenience APIs which take care of the details, including<br>
> low-level functionality (like actually sending and receiving requests,<br>
> processing responses, "packaging" data into language-appropriate data<br>
> types and containers, ...).  As a matter of fact, they could even be<br>
> made to deal with issues such as service API version differences and<br>
> capabilities.<br>
><br>
> Then, rather than having to write all sorts of low-level code to use<br>
> the service API, 3rd party applications (or short scripts or ...)<br>
> would simply make a couple of (language-appropriate method) calls<br>
> through the bindings to get the functionality they need.<br>
<br>
Oh, and I should probably say that any 3rd party app developers should<br>
feel free to develop their MythTV-service-API-using code into a library<br>
which could become bindings for the chosen development language, rather<br>
than writing "one-off" code  that's only usable by their own<br>
applications.  My only suggestion would be to communicate your<br>
intentions so that we don't have multiple independent projects working<br>
on the same goal (same language).<br>
<br>
Mike<br>
_______________________________________________<br>
mythtv-dev mailing list<br>
<a href="mailto:mythtv-dev@mythtv.org" target="_blank">mythtv-dev@mythtv.org</a><br>
<a href="http://lists.mythtv.org/mailman/listinfo/mythtv-dev" rel="noreferrer" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-dev</a><br>
<a href="http://wiki.mythtv.org/Mailing_List_etiquette" rel="noreferrer" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a><br>
MythTV Forums: <a href="https://forum.mythtv.org" rel="noreferrer" target="_blank">https://forum.mythtv.org</a></blockquote><div><br></div><div>What about introducing something like swagger into the automated builds so that it produces not only the api documentation, but also various clients in the language of your choosing?</div><div><br></div><div><a href="http://swagger.io/">http://swagger.io/</a></div><div> </div></div></div>