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.
Senario:
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.
Ideas?
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>