[mythtv-users] Mooting architecture for a DataDirect replacement

Michael Jones mythlist at michaelandholly.com
Thu Jun 21 03:21:16 UTC 2007

Ok.. if the SQL only is too "myth specific" try this on for size... :-)

If the data were in an SQL database, a frontend on the service could  
EASILY export it to a file, if that's what the user/subscription/ 
preference whatever decided.  The point is not the format that is  
used.. since the contents of the SQL database can be output into  
almost any format imaginable at the drop of a digital hat (usually  
measured in milliseconds).   Keep the format in most general,  
manageable format and distribute it as needed.


A)  My system runs MythTV, I have an SQL grabber of some kind that  
makes a request from the parent server every X minutes, this request  
contains the market I need and the last time I did an update.   The  
parent server retreives all changes since that time for that market  
and sends it to me in some sort of compressed stream, my SQL database  
updates itself from this data and all is good.

B)  The guy down the street has X system.. his needs are Y.. he has  
some sort of grabber that communicates with the front end every X  
minutes, the query contains his market and the last time he made a  
query and the parent server retrieves the information and sends it in  
a compressed text stream that his system parses and imports into it's  
proprietary format.

C)  The guy further down the street has Z system, his likes XML  
data.  So his server talks to the parent.. sends the proper codes..  
blah blah blah and magically in his email inbox arrives an XML data  
file that he manually parses and does whatever his little heart  
desires with it..

D)  Another user loads up a PHP web front end, types in his market,  
zip, whatever and up pops the full channel lineup for his region that  
he is free to peruse on his web browser.

Ok.. Here's another one..

E)  Another system takes RSS feeds.. the back  end SQL brain exports  
the pertinent data into the proper format via PHP, Java or somesuch  
and the RSS based client system sucks up the data as it wants it..

Here's the unique part of the whole thing.   The data is in a format  
that can be repurposed and exported, published, pushed, pulled,  
sucked and .. well you get the idea...  to whatever the need is.     
The point is keep the data in a predictable, stable, accessible  
format on the back end have the front end (or multiple front ends)  
manage the publish action with the data.   The data is system- 
independent.   If the user needs only a small portion of data, that  
data is provided and it reduces the number of bits transmitted and  
therefore the load on the parent system.


Hey.. I know Chris likes it already ;-)  If the system were designed  
correctly it could even publish the data the correct format for  
DataDirect if that's what Myth sticks with.

- Michael

On Jun 20, 2007, at 10:52 PM, Peter Schachte wrote:

> Michael Jones wrote:
>> Rather than creating a downloadable, encrypted file which must be
>> downloaded in its entirety why not create an SQL database which
>> tracks the programs on in a specific market.   Have the Mythtv Log
>> into this database query for that system's market and only update
>> records which need updating?
>> This should reduce downloads significantly since the only information
>> that needs to be downloaded is new information or information that
>> needs to change since the last download.
> That sounds like a good way to do it, but it's rather myth-specific  
> and would
> require a fair bit of work.  You could get most of the benefit in a  
> more
> application-neutral way with much less effort by working with XMLTV  
> files.  You
> could just always keep the last XMLTV file you downloaded, and then  
> use
> something like rsync to update it before reloading it into myth.
> -- 
> Peter Schachte              We hang the petty thieves and appoint  
> the great
> schachte at cs.mu.OZ.AU        ones to public office.
> www.cs.mu.oz.au/~schachte/      -- Aesop
> Phone: +61 3 8344 1338
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

More information about the mythtv-users mailing list