On 13/01/2012 19:10, Cowboy wrote: > On Friday 13 January 2012 02:02:06 pm Fred Gleason wrote: >> although writing and polling a timestamp in the DB might be viable as well. > Certainly not the most desirable solution. > How much time before a lock is considered stale ? > 10 miliseconds ? > 24 hours ? > What if someone has opened a file for edit, forgot to close, > and left for the weekend ? It could happen. > Ridiculous ? Maybe. > Forseeing the possibilities, and unintended consequences, > is the hard part. > > Perhaps a lock that can only be removed by the process creating it, > OR by an administrative over-ride. Admin manual intervention. > This is why I originally tended away from the locking issue and gravitated towards global instant updates. It gets messy...
Perhaps it's best to consider alternative solutions. If you could create a log which behaved as a normal log but was actually composed of multiple logs under the hood, then much of this problem could be avoided. Call it a metalog - you make a daily metalog which consists of all your logs for your shows (each one a metalog entry). Each show can then edit their log without breaking anyone else's logs, and in rdairplay the whole shebang is treated as a generic log; edits are made to the underlying logs, playout is as if it were one continuous log. I'm going to assume/sort of know this would be a heck of a lot of work to implement, but it might end up being a more flexible solution that could solve other problems in similar areas. If it's a choice between one large project and another large project, there's a good argument for making it at least a project that adds functionality rather than limiting it... _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
