>After that, you define your own schemas as you like. > Yes, but how many end-users are really going to do that? And the scanner/API has to be written to cope with different schemas.
>It sounds extremely flexible, but it also sounds like some simple >capabilities could be lost. > 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). >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...). My main concern will be speed. 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. _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/ripping
