Philip Meyer;379727 Wrote: > >After that, you define your own schemas as you like. > > > Yes, but how many end-users are really going to do that?
Probably very few. The default schema will satisfy them. I suspect, though (if it's implemented well) that users may _share_ schemas. For instance, someone creates a schema that deals well with Jazz albums, and other people install it on their systems. One thing I don't like about this (if I understand it correctly) is that it may require partitioning your whole library into individual libraries with custom schema for different music types. That doesn't sound convenient. > And the scanner/API has to be written to cope with different schemas. No, that's exactly what the scanner does not have to do. The scanner just reads (all) tags and stores them. There's just one base schema used for the database and tag storage. > I've never seen any projects do well with extremely flexible DB schemas. > A single well-known rigid schema is needed (it may define data > generically for an object relational mapping). That's why I say it will be difficult to get away from the current method of recognizing certain well-known tags and fitting them into a rigid schema. ALBUMARTIST, for example, has meaning that goes beyond just being another tag that you can search and sort by. Maybe the way it will be implemented is to keep the current database schema of albums, tracks, contributors, genres, etc, _plus_ have the "every tag that gets read" tables storing arbitrary tags on which flexible schemas can be defined. > > >I expect many of the same problems regarding how tags are interpreted > > and used by the server to continue. > > Problems can be fixed. I expect grief with old bugs resurfacing, new > bugs created, and some existing bugs not solved because they are not > seen as critical for the mass market (i.e. there will be some things > that will be possible to fix, if you want to create your own schema, > scanner and API updates...). I expect that too. I can't see any of the old problems going away with a new database organization. Many of them aren't about a lack of flexibility, just an inability to solidly define expected behavior and a willingness to implement it. > And because the schema is now seen as private (shouldn't be accessed by > external apps), there will be a larger reliance on the CLI to access > data. Some plugins/applications (such as Moose) could be too slow to > be practical. Moose could define its own schema if it likes. As long as the db structure is understood (and doesn't change too often) it could still access the db tables directly. Dealing with both SQLite and MySQL, though, will probably be too much and I expect an app like Moose would require the user to use MySQL. -- JJZolx Jim ------------------------------------------------------------------------ JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=57594 _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/ripping
