[mythtv] New Protocol Development

buzz davidbuzz at gmail.com
Tue Sep 23 05:25:09 UTC 2008


>
>  So please,
> share your ideas.


Ok.   My idea is that mythtv needs two protocols:

ONE: for short-lived request-response (like fetching settings, sending
individual program info)  SOAP, XML_RPC, might be appropriate here.
something lighter and faster but logically comparable  is 'protocol
buffers': http://code.google.com/apis/protocolbuffers/
TWO: is a protocol for streaming.   this needs to be a binary, low-overhead,
long-lived, error-recoverable protocol.
eg: RTP/RTCP see  RFC3550 ( often used in conjunction with RTSP, but they
are different: RTSP = RFC2326)

- 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

...or it could be used quite well for 1/2 the issue, and hand-off the binary
streaming to something else.

<snip>
> - The protocol does not have the capacity to deal with protocol version
> changes and feature changes without occasionally (often?) breaking
> compatibility with older versions.


Oh, and BTW - protocol buffers  supports extensability of the protocol.
here's the C++ protocol buffers tutorial:
http://code.google.com/apis/protocolbuffers/docs/cpptutorial.html

Buzz.

Personally, I don;'t care too much either way... as it works OK now.    of
course, if it itches, you can scratch it.   :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20080923/009da569/attachment.htm 


More information about the mythtv-dev mailing list