[mythtv] Feature Request/RFC: A stable, extensible, third-party usable API

[Robert Johnston]

At the moment, it seems that if an application wants to work with Myth 
in some way, they have to be running on the Myth server itself, and use 
it's perl or python bindings.

This is very much a less-than-optimal system for third parties trying to 
work with Myth, and while some attempts have been made to overcome this 
(libcmyth, for example), the difficulty in tracking the multitude of 
changes to Myth's internal protocol make this difficult. And with the 
entire lack of support from the Myth community itself, next to impossible.

What I propose, therefore, is an open standard, that (most importantly) 
will remain compatible whenever it is upgraded.

I'm thinking of a SOAP/XML or JSON type system for sending data back and 
forth to third party clients that choose to implement the standard.

For instance, a call to:

http://backend/GetRecordings

Would return:

<xml>
<RecordingList filterable="Name,Title,Series,Date,Time,Channel,Group">
<Recording id="1016_201001011905" Start="2010-01-01 19:05 +0000" 
End="2010-01-01 20:25 +0000">
<Title>Sample Program</Title>
<SubTitle>First in a new series, "Sample Program" brings together the 
best of samples, and programs</SubTitle>
<HasCommSkip />...
<Stream>rtsp://backend-that-holds-the-recording/Stream/1016_201001011905</Stream>
<Download>http://backend-that-holds-the-recording/Download/1016_201001011905</Download>
</Recording>
</RecordingList>

(Noting that it's the backend that holds the recording, not necessarily 
the MBE, that streams the recording to the client)

The streaming could be RTSP, or simple HTTP, so long as it supported 
seeking.

The "Filterable" means the list can be whittled down like so:

http://backend/GetRecordings?Title=Get%20Smart&Channel=TCM

And recording groups could be secured, requiring:

http://backend/GetRecordings?Group=Naughty%20Porn&PIN=12345

A call to:

http://backend/GetCommercialList?ProgramID=1016_201001011905

Would return:

<xml>
<CommList>
<Commercial Start="1005" End="55658" />
<Commercial Start="55999" End="98445" />
</CommList>

It also means that recordings could be scheduled from this interface 
(Using a POST), upcoming recordings could be retrieved, program listings 
could be shown (Exported as XMLTV, with a few additional flags for "Has 
been recorded", "Will be recorded" and so on, for example).

With this using web-technologies, it would then be possible for people 
to build home portal start pages with "What's new to watch on TV", to 
assemble an RSS feed of certain shows for consumption on a mobile 
player, easier integration with other programs or systems that may want 
to extend the data (GoogleTV, AppleTV, Boxee, XBMC, Windows Media 
Center), to make a bookmarklet to schedule a show when you see an ad for 
it on the web...

The whole system could be easily securable (using SSL, or by issuing an 
Auth "cookie" or code that has to be passed to identify the program, or 
both)

I realise that some of this could be done using MythWeb, or the 
Perl/Python bindings to a web page/site (Though I think the streaming of 
recordings wouldn't be possible like this), but my thinking is that this 
kind of interface should be a built-in part of the MythBackend. It 
already has a web server built in, this is merely(!) giving that 
webserver something to serve other than the status page.

None of these are requirements, nor are they set in stone, but from what 
I can see this will be the first attempt at an externally-accessible API 
for Myth.

I look forward to your comments.