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.
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
