gnump3d-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ADV: [Gnump3d-devel] Database backend


From: Steve Kemp
Subject: Re: ADV: [Gnump3d-devel] Database backend
Date: Sun, 5 Dec 2004 14:30:10 +0000
User-agent: Mutt/1.3.28i

On Sun, Nov 28, 2004 at 10:14:16PM +0100, Martin Lohmeier wrote:

> I'm using gnump3d for years and my collection of music has grown up to ~550
> songs.

  550 songs doesn't seem like too large a collection.

> Unfortunatelly I noticed that it takes a lot of time to open the
> webinterface [1]. So I think the parsing ot the cache file takes so long,
> does it? How complex would it be to use a Database (mysql?) to store the
> information in? And would it speed things up?

  It's not the cache file parsing which is taking the time, it's the
 creation of the cache file.  This is treated as a pseudo database.

  I've been in two minds about a real database, but mostly I'm against
 it.

  Pros
  ----

   * The tag file lookup is fast.
   * Searching, sorting, and randomisation are trivial.


  Cons
  ----

  * The database must be updated every time new media is added.
  * Setup instructions are going to widely vary, depending on the 
    database used.
  * Suddenly we lose the ability to run on lower-end machines and
    likely Windows machines.
  * We have to lookup songs twice[1]
  * The dependencies required to run the software increase.


  [1] The song lookup issue is probably the blocker for me.  If we
 assume that when the server is installed a find for media is made
 which enteres all the song details into a database, then it seems
 "nice" to just select all the songs from there instead of from the
 filesystem.  This is fast, reliable, and simple to do.

  However it breaks down the moment the database copy of information
 goes out of sync with the filesystem.

  My solution would be to scan the filesystem for songs, then use
 the database for just getting the tag information.  This is essentially
 what happens with the cache file at the moment.

  If I were to write the code again I'd insist that the database 
 contents were current, and then use that exclusively.  However I
 suspect that the majority of users wouldn't like it.

  Perl modules could do most of the hard work:

        Class:DBI - Database lookups.
        HTML::Template - For the output pages.

  (NEVER Again would I attempt to create my own templating system.
 Still a nice lesson learned :)

Steve
--





reply via email to

[Prev in Thread] Current Thread [Next in Thread]