[mythtv] Questions about Python bindings

[Rebecca Sutton Koeser]

George, thanks for the info about IRC and the vote of confidence.

Raymond, thanks for taking the time to respond and give me a better idea of
the current status.

On Tue, Apr 16, 2013 at 10:07 AM, Raymond Wagner <raymond at wagnerrp.com>wrote:

> Considering all the language bindings are currently tied to a specific
> version
> of the database schema and backend protocol, keeping them all in the same
> repository makes it easier to manage compatibility and ensure they get
> updated to match changes in the code.  For these reasons, I would be
> reluctant to break them out into their own repositories.
>

Hmm, I see.  Could keeping it included in the main repostiroy as a git
submodule to accomplish the same thing (or nearly the same)?


> > and in one case where I think it is, it needs a small fix-- something
> I'd like to
> > submit as a patch but I'm hesitant to fork the entire myth repo for a
> one-line
> > python change
>
> Then don't fork it.  You don't need to fork something just to make a patch.
> You don't even need a Git checkout.  Just copy the file in question, make
> the
> change in the copy, and `diff` the two.
>

Yes, sure, that's fine for a single line change.  But what about more
substantive contributions like adding new service implementations or
fleshing out the documentation?

> Is adding support for the services API planned? Is that something that
> belongs
> > in the bindings or is outside the scope/intent of these?
>
> When the bindings were originally rewritten several years ago, the
> Services API
> didn't even exist.  There was a much more limited MythXML interface, but
> nearly everything you might want to do with the bindings required
> interfacing
> with either the database or the backend protocol.  The bindings were
> designed
> to duplicate many of the structures available through those two interfaces.
>
> The Services API, while already far more capable than the old MythXML, is
> still
> relatively limited.  It's basically being grown organically as someone
> wants to add
> a new feature for the in-development backend configuration page, or for a
> 3rd
> party client like Torc for iPad or UbuntuTV.  There will still be a need
> to access the
> database and internal protocol for some time.  The plan is to add an
> abstraction
> layer on top of the existing classes to allow interaction to shift between
> one
> interface and the next as needed.  There already is some degree of this,
> as there
> are methods that will return Program or Guide objects built from the
> responses
> of the Services API, but these are one-off implementations, rather than
> some
> reusable framework.
>

Thanks for explaining this.  I had guessed that something like this was the
case based on the different functionality that I was finding in different
places.  I've also seen just in my preliminary investigation that the
Services API don't yet include all of the functionality I'm interested in,
some of which is already exposed in other ways in the python bindings.

The abstraction you're describing sounds great.  That's how I was thinking
I'd like to see things organized as well.  Do you have enough of a plan for
this that someone else could help out with implementing it?


> The database access classes are largely auto-configuring already, and the
> internal
> protocol classes are easy enough to set up, so that leaves an interface to
> the
> Services API, and the layer on top to tie it all together.  I have a base
> class mostly
> written that will generate its own interface to the Services API based off
> the
> available WSDL sheets, but I stalled some time back when I ran into an
> issue where
> the Services API would document a generic type when it using a list of
> complex
> types.  I believe David Blain has fixed this issue, but I've been busy with
> other things and never got back to work on it.


Sounds promising.  Is the code on github anywhere?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130416/f5bd3a9e/attachment.html>