I think that it would be pretty nice to have the option to have an external database accesable from other systems. Just such a simple thing as my media library is remote means I would like to have my database remote. I think of freevo as thin frontend to my media library. Something I want to access from various places. I would like to be able to integrate freevo into my webpage (to complex to fit inside freevo) to be able to get things like "top 10 songs listend to last week". I would also like to have my music store index when I add new songs to improve speed. This might be posible with freevo, but again my media store is not located on the same computer that runs freevo. There are several other reasons as well so some form of pluginable persistance I think would be nice.On Fri, Jan 23, 2004 at 07:48:32PM -0500, Michael Ruelle wrote:Having gone through in my professional service the transition from one database to another I would advise against this. I was going to bring this up with dischi, but will state my piece here.Considering most of the db stuff has been mine so far, that's probably best :)I would suggest the plugin stategy, we have used successfully elsewhere. Failing that I would rather see a rpcxml (or some other web service API) or at the very least the judicious use of the Business Delegate design pattern to keep the SQL as far away as possible from real code and just use abstract methods and objects from our software rather than some class from the database interaction layer.That's probably fine, but I'm still not sold on a network-aware DB like MySQL.... the benefits are questionable when the webserver, recordserver and GUI core are all happy to talk over HTTP/XML...
BTW are there any where I might find info in what the current DB persistance does/how to extend it ?
I have quite alot of features I would like to see added to it and am currently builiding my own, and it seems pretty silly do the work twice :)
What I would like to store inside the DB is such things like all ID3v2 tags, playlists, etc, etc...
// Michael Medin
This we can define the interface and not have to conform to some individual piece of SQL softwares view of what the standard is. And believe me they widely vary. And can use the best thing available. Also someone may even what to use an object database too (right now it maybe a stretch but one rarely gets a straight answer from the magic eightball).This is true, but also consider the fact that what is happening right now is that SQLite is used to log music ratings and play times. None of this is particularly complicated, but I'm using a database because performing queries against a pantheon of mmpython cache files is time consuming. I don't like the idea of remote DB calls, and I think using the existing network-aware functionality to handle network transparancy is more reasonable. If we put the TV guide into a database, SQLite is a good option because it's a single file with minimal requirements on the user end. It's faster than a pickle and it's easier than MySQL. ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
