Brad, like I said earlier, - it's a lot of work for little effective gain and opens up a number of holes or potential areas for concern.
I think we just need to accept that very infrequently shit happens and move along. Cheers, Dean > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:mythtv-users- > [EMAIL PROTECTED] On Behalf Of Brad Templeton > Sent: Friday, April 29, 2005 6:21 PM > To: Discussion about mythtv > Subject: Re: [mythtv-users] How to handle schedule pre-emptions? > > On Fri, Apr 29, 2005 at 02:39:07PM -0700, Brad Templeton wrote: > > Well, if some brave volunteer wanted to offer a service to notice pre- > emptions > > and broadcast database updates for the networks, I could produce code > > to read these off the web or an e-mail to update the database. > > > > A mailing list seems the most efficient, but it means that each user > > has to know how to redirect a mail or an alias into a process (such as > > a perl script.) That changes from system to system so it's not really > > possible to have it slotted in out of the box. > > > > Far less efficient would be polling a web address. That could work out > > of the box but it's a _lot_ less efficient and depends on you polling in > > time. > > > > But the main thing is somebody willing to be the trusted party who > > sends out updates. You would write up the updates in something > > similar to the SQL that would be executed. > > With a bit more thought, I came upon some additional realizations. > > One more secure approach would be to send the zap2it style XML with > updates, and feed that into mythfilldatabase. > > (One could also consider just a signal to tell the system to run > mythfilldatabase with an argument telling what site to fetch data from. > However, that would still need to be secured, as otherwise it could > cause a DOS attack) > > However, it also occurs to me that unlike me, many people may not have > a mail server running anywhere that can connect to their SQL database. > While one could tunnel or play other tricks, the e-mail route might > leave a number of users unable to easily use the system. > > The alternatives aren't great though. One would be to develop an "alerts" > daemon in Myth. This daemon would listen to a port (could be any port) > for a very simple command set. One would need to open a firewall/NAT > hole > to the port, and because of the security risks of doing so, the command > set for the port would be very small, and the commands probably signed > with a crytographic digital signature. The commands would probably not > contain any data, they would be more along the lines of "You should > resync your database now" or "go get database updates from this IP > address." > > (Alerts could also still come via email for those who could handle that. > The alert could just trigger the same thing or even talk to the hidden > alerts port.) > > While one obvious app is real time database update notifications, this > port could also exist for future collaborative or P2P applications in > the system. > > This is all a lot more work. E-mailed mythfilldatabase XML or SQL would > be vastly easier to implement, but I presume there are many who can't > get E-mail anywhere in range of their myth box. (You could install > an MTA on your myth box but that's pretty drastic.) E-mail, unlike an > alerts port, has lots of extra reliability measures to assure delivery.
_______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
