[mythtv] Questions about Python bindings

[Raymond Wagner]

From: Rebecca Sutton Koeser
Sent: Sunday, April 14, 2013 6:36 PM
> First, I was wondering if it would be possible to break out the language
> bindings into their own git repositories?  It seems like that would make
> it a lot easier for people like me, who may have expertise in a particular
> language and are somewhat familiar with MythTV, to contribute fixes,
> documentation, etc for the bindings they want to use and/or the language
> they are familiar with.  

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.

> 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.

> 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.

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.