[mythtv-users] Mooting architecture for a DataDirect replacement

[Mike Perkins]

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.