[mythtv] New Protocol Development
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
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.
> - 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:
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...
More information about the mythtv-dev