[mythtv] New Protocol Development
kkuphal at gmail.com
Tue Sep 23 20:01:20 UTC 2008
On Mon, Sep 22, 2008 at 10:12 PM, Glenn <subscribe at clubpoint.net> wrote:
> I've recently been looking into development of apps interfacing with the
> backend, and found a quite incomplete protocol spec/docs, and also came
> across the dev note that a new protocol may be required.
> Rather than simply diving in, developing a new protocol and saying "here
> it is", I'd like to put some ideas together, develop a spec, and then get
> feedback and so on prior to simply slapping something together. So please,
> share your ideas.
> So far, from my searching of the archives, I found a few mentions of a new
> protocol, but no real work towards it. A few things I found (please note
> that I'm really quite new to mythtv):
> - Upnp has been worked on, but is simply too 'heavy' to be used as the
> primary protocol, so will likely remain as an 'extra' protocol
> - XML-based protocols or similar are likely to also be too 'heavy', and
> parsing will therefore be too CPU intensive for low power systems and so
> on. New protocol must be easy on the processor!
> - MythXML has been worked on somewhat and provides things like Program
> Guide data
> So in summary, there are currently three protocols, none of which provide
> all services, which I'd like to change. Other observations I've made:
> - The MythTV protocol isn't clearly defined/documented anywhere (the wiki
> contains partial specs through reverse engineering)
Why isn't the effort simply focused on documenting the existing protocol.
Apart from that, there really isn't any deficiency in the protocol.
> - The protocol doesn't use any authentication
It could, it just doesn't. Not an issue with the implementation, just not
an implemented feature
> - The protocol does not have the capacity to deal with protocol version
> changes and feature changes without occasionally (often?) breaking
> compatibility with older versions.
Again, not an implemented feature and as far as I see it, not really
necessary to a large degree because when the protocol changes, it is
typically for a reason that something has changed significantly such that
older clients should not be communicating with the newer backend and
I'd rather see people spending efforts documenting the existing protocol and
improving the UPnP support because ultimately, the better the UPnP support,
the more clients Myth will work with for playback, even if other advanced
scheduling features and such aren't present. Also having UPnP client
support in the frontend would let the Myth client work with more backend
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-dev