From: Aubin P. <au...@pu...> - 2003-06-30 14:45:32
|
On Mon, Jun 30, 2003 at 09:02:20AM -0500, Krister Lagerstrom wrote: > It would be nice if the security is layered outside of the database and > the queries. I don't think it will be possible/desireable to parse all SQL > queries to find "bad" code. It is better to restrict access to the machine > instead. I agree; but I mainly figure, that for most playlists, you don't need to do a 'select songs' We're going to have to expand that into 'select path,filename' anyway, so we might as well assume that it's going to have that. And of course, without a WHERE clause, it's useless too. > I've never seen SQLite before you started working on it, but I'm pretty > impressed by what it claims to do and that it is so easy to integrate with > Freevo. I've used MySQL/Python a bit, and while it is powerful I'd never > want to make MySQL a requirement for the basic Freevo functions due to > install/setup issues. It's very cool. I don't like MySQL both for it's requirements (it's complicated for most people) and because it doesn't provide much advantage to justify the requirements. SQLite is astoundingly cool. The debian packages (shared library plus python module) occupy about 350k on the system, and require no user configuration. It actually supports more of the SQL spec then MySQL and claims to be faster for most operations. > SQLite on the other hand could easily be made part of the standard Freevo > setup IMHO. For instance, it looks like a pretty elegant solution to the > problem of displaying 10000 MP3 songs that the user put in a single > folder... Not to mention issues around the TV guide... though, in fairness, since we switched to the binary pickle format, the loading time is barely noticeable. (It used to be a slight delay between hitting "tv guide" and seeing the guide, now it's instantaneous on my very slow computer) Aubin |