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

[David Shay]

Question to Isaac, et. al.

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.  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.

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.

Also, although dbus looks like it could certainly be OK from a 
myth-to-myth protocol, it doesn't provide as much of an opportunity for 
embedded platforms with easier bindings.  Dbus does provide Qt bindings, 
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 
directly as it is.  On the other hand, something like xmlrpc provides 
both Qt bindings as well as C/C++ bindings.  It also seems to be a 
decent middle ground between complete web services and something like 
dbus.  Dbus also has an XML library dependency as well (expat or libxml) 
which xmlrpc wouldn't.

Just some thoughts, looking for input.