[mythtv] Development to-do list question -- protocol

[Daniel Kristjansson]

On Tue, 2005-11-01 at 00:01 -0600, David Shay wrote:
> With respect to the item around changing the protocol.  I would be 
> willing to help with this item and have started some research into 
> dbus.
How good is DBUS support on OS X and Microsoft Windows?

> Before digging much deeper, though, I'm wondering what your 
> thoughts are on having two different protocols -- one for high-volume 
> data transfers where video data is being transferred and the other for 
> all of the other portions of the protocol -- scheduled recording lists, 
> tuner status, etc.
It is better to have one protocol, but you could still allow video data
to be streamed via a streaming protocol. We already open up a separate
socket to stream video. It would be nice to have the option of swapping
out one streaming protocol for another (say TCP for reliable ethernet
connections, and some UDP protocol for WiFi).

> One of your consistent comments about using an XML based protocol has 
> been that this would be inefficient where there are hundreds of calls 
> per second.  By splitting the protocol, you could use an efficient 
> protocol for the relatively stable file-transfer functions, but an 
> XML-based flexible one for the more evolving portions.  An XML approach 
> would allow other applications to be more resilient to minor protocol 
> changes, like adding a field to the ProgramInfo structure, since it 
> could just ignore items it wasn't prepared to deal with.
Issac will have to answer you on this. I personally think XML is 
overkill for a lot of things, but would be OK for passing things
like ProgramInfo.

> but on the embedded side you would be dealing directly with libdbus, 
> which isn't a whole lot easier than dealing with the myth protocol 
We would probably want write our own wrappers anyway so I wouldn't
worry about this.

-- Daniel