Brad Templeton wrote:
Is this because it's difficult to get SQL libraries for the mediamvp?
I don't know about difficult, but they've implemented the code already
to do the Myth protocol and not to do other functions which don't exist
in the protocol so it only makes me think that perhaps having more
functions in the protocol where they make sense could be beneficial to
their (and other clients) efforts.
It seems risky to me to have to support two different ways to do the same
thing. If it's something only the backend can calculate, such as the
output of the scheduler, that makes sense -- is that what you have in mind?
My thoughts were to expand the myth protocol, not create duplicate
methods. A SOAP interface, while "extraneous" in the sense that you
already have the myth protocol, might open up the door to other clients
and can be simply another layer of interaction. The advantage for SOAP
and other client protocols by having more functionality in the Myth
protocol is that they simply have to call the same functions called by
the Myth parser. No code duplication, only multiple points of entry for
the same end function which ultimately opens up the usability of Myth to
a larger audience.
Kevin
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
