[mythtv-users] Mooting architecture for a DataDirect replacement
mikep at randomtraveller.org.uk
Sat Jun 23 15:21:39 UTC 2007
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.
> 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; 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. 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.
> 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.
Sounds to me like you might be describing certain aspects of SVN. Nice,
big, steadily increasing version number, etc.
More information about the mythtv-users