What if we added import-time metadata support, where each track gets tagged with the metadata present when it's imported. Then we simply ignore these tags after import. Sure, updates to the DB would lead to inconsistent metadata in the file tags, but I imagine updates are already pretty rare (we almost never change tracks after adding them to Rivendell). If we wanted to support basic updates, we could just add a batch job that reads through the Rivendell DB and updates the metadata on each track offline, to be run manually at static sync points as required. I think such a solution would be adequate for 95% of the suggested use cases, and would at least provide basic redundancy in the event of a catastrophic database failure or the desire to access the tracks via a non-RD-database-aware program.
If we really wanted to add full, synced metadata support, I think the correct deign pattern would simply be to make tracks immutable. If you ever have to "update" a track/metadata, you instead create a new copy of the track with the new information, leaving the previous copy as is. Then these previous copies could be tagged for depreciation (avoiding their use in future logs while also not breaking any use in existing logs). Kind of like a versioning scheme for tracks. This would avoid the "track in use", etc issues, and would follow the fairly common modern design pattern for dealing in an "objects are cheap, consistency is hard" world. Not that we need to make this overly complicated. Like I said above, simply tagging the tracks at import and then forgetting about the fact that they have tags (possibly with the ability to run an offline update periodically), would probably suffice. On Wed, Jul 3, 2013 at 9:11 AM, Fred Gleason <[email protected]>wrote: > On Jul 1, 2013, at 14:24 55, Bill Putney wrote: > > > I wonder how you'd convert to FLAC and imbed the metadata from they > library you have. You'd have to get the data out of the RD database and put > it in the FLAC header? That's a big conversion job on it's own. > > And that's just the start of it. Suppose someone comes along later and > changes some of that metadata in the database -- now you have to update the > copy in the audio store as well. Flat files are just not well optimized > for these sorts of updates. Suppose that file is currently in use? Do we > defer that write somehow? Suppose that queueing mechanism itself becomes > corrupt? And so on... > > I'd as soon try eating soup with chopsticks. Instead, let each subsystem > do what it does best. > > Cheers! > > > |-------------------------------------------------------------------------| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |-------------------------------------------------------------------------| > | I looked out my window, and saw Kyle Petty's car upside down, then I | > | thought "one of us is in real trouble". | > | -- Davey Allison, on a 150 mph crash | > |-------------------------------------------------------------------------| > >
_______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
