Re: [Mvpmc-devel] MythTV architecture weaknesses

[Kevin S. <mv...@ke...>]

On 19/11/10 21:09, Tom Metro wrote:
> Does it strike anyone else that the MythTV architecture is rather broken
> if a client like mvpmc needs to interact directly with the MythTV
> database, and is impacted by schema changes?

[I'm a long-time user of mvpmc and MythTV and lurker on the mvpmc 
mailing lists, but only a novice C programmer.]

I agree that MythTV clients shouldn't have to change every time MythTV 
does. Worldwide best practice is for clients and servers to interoperate 
through a well-defined protocol and my preference is for that protocol 
to be an open specification.

In my opinion MythTV, by not wanting to standardise their protocol, are 
following a path doomed to failure as modern customers want to pick and 
choose components from different suppliers. I do appreciate that having 
a standard protocol slows innovation, which is what MythTV is all about.

The Digital Living Network Alliance (dlna.org) seems to be trying to 
address the interoperability problem and their standards have been 
adopted by the International Electrotechnical Commission (IEC), but 
sadly the standards aren't Open or available to non-members without 
large costs and restrictive conditions. I haven't been able to find any 
other attempts at creating media device interoperability standards (but 
I'd welcome any information.)

As Free Software developers, I see two choices for us:
1. Create an open standard for media devices to interact and hope that 
easy availability of the standard and source code will cause more 
hardware manufacturers to adopt it, or
2. Write software which interoperates with DLNA devices we own as best 
we can.

With more devices running Linux everyday, I believe that device 
manufacturers would welcome the prospect of not having to write or buy 
interoperability code, making choice 1 a good path to follow in the 
medium to long term.

For mvpmc and libcmyth, a short-term solution might be to follow option 
2, considering that MythTV already provides some uPnP functionality. 
That would give mvpmc some insulation from MythTV changes, even if uPnP 
doesn't cover all the functionality mvpmc/libcymth requires. The greater 
number of people with devices requiring uPnP will hopefully create more 
incentive for the MythTV developers to keep their uPnP layer operational 
when MythTV protocols change.

I'll keep looking into this issue, as it combines two of my favourite 
topics: Open vs Closed standards and Home Networking - I'll let everyone 
know if I find anything useful.

Lastly, thanks again to everyone who contributed to mvpmc and MythTV - 
you've given me many years of 'lean-back' entertainment!

-Kevin

---
Have a vacancy for a Network Engineer/IT guy in London, UK? Please let 
me know.