[mythtv-users] Mooting architecture for a DataDirect replacement

Jay R. Ashworth jra at baylink.com
Sat Jun 23 19:20:37 UTC 2007


On Sat, Jun 23, 2007 at 11:23:35PM +1000, Peter Schachte wrote:
> Rod Smith wrote:
> >>> I used net news back in the day.  My memories are of out-of-order
> >>> messages, replies to messages that never-ever came through, and other
> >>> general annoyances.
> > 
> > For the application under discussion, out-of-order postings don't matter;
> 
> If there are multiple updates to the schedule in separate postings, I don't
> think this is true.  If there's an update that says that station X is airing
> program Y at time Z, and another update sent an hour later that says no, it'll
> be at time Q instead, then you don't want to handle them in the wrong order.

Date-Posted:

If they come in out of order, you can remember when the latest update
applied was posted and ignore the older one.

> I believe the OP suggested we consider requirements for this
> system. As much as I like usenet for discussion forums, I think the
> requirements for our purposes here are rather different. One key
> requirement for us is that distribution be reliable;

Reliable is a quotient, not a binary flag.

>                                                     ie, at all times,
> every subscriber should have the correct schedule for their lineup as
> at the time of their last update. Another is that if something goes
> wrong and somehow myth doesn't have the correct schedule, it should
> be able to tell, and be able to correct it. It's hard for me to see
> how to satisfy that with NNTP. If postings get lost or come in out of
> order, the schedule winds up wrong.

Only to the extent that changes are made after programs are scheduled
into automation, and to a large extent, this depends on how reliable
your NNTP infrastructure is.

>                                       The problem could be detected if
> each posting contain a checksum for the whole lineup after the change
> in the posting is applied (not just for that posting). But if the
> checksum fails, what can you do? If you drop the whole schedule and
> reread all the postings from the same host, you'll just get back the
> same wrong schedule. You need an authority to go to to get the correct
> data.

And since I'm mooting each posting generally being one or a small block
of events, there isn't any whole schedule to request.

> Someone else suggested bittorrent for this, and it actually has some
> properties that make it quite appropriate. Namely that there is a
> central authority anyone can go to to find out what updates have
> been published (as torrents), but the data itself can be efficiently
> downloaded from peers. And each update would have a cryptographic
> hash, so any corruption would be detected. It's also friendly to
> binary data, so the udpates could all be compressed to decrease
> bandwidth requirements.

But as was noted, and as I myself see, the crntralized part of the
infrastructure is too top-heavy... or more correctly: it imposes
possibly unwanted structure on the data: you would *have* to package up
updates...

and if we want stations' automation scheduling systems to push the
data, we pretty much have to take it as they give it... which is why I
wanted the built in caching of NNTP.

Cheers,
-- jra
-- 
Jay R. Ashworth                   Baylink                      jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


More information about the mythtv-users mailing list