Re: metadatabase

On Wed, 15 Oct 2003 10:37:00 -0700, Kristian Kvilekval <[email protected]> 
wrote:

> On Wed, 2003-10-15 at 10:18, David Hough wrote:
...
> Again how would this co-exist would recursive playlists?
> Should the current index be of the entire expanded list?
> Just to be clear the player has it's own idea of a what
> a playlist is.. The current UI may have several playlists,
> only one of which needs to be consistent with the player's.
> For example:
>
> Player playsheet
> 1.  file://song1.ogg
> 2.  file://myfavorites.m3u
> 3.  zinf://url?genre=ambient
>
> While the UI may show:
> 1.  file://song1.ogg
> 2.  +file://myfavorites.m3u
> 3.     file://song2.ogg
>         ...
> 99. +zinf://url?genre=ambient
>        file://song10.ogg
>        ...
>
>
> The concept of index may not make too much sense
> if we allow this.   However, URL's do not and should
> not need to be unique (though I have seen a request
> that there be option in the playlist to ignore
> additional adds of the same song).   I am beginning
> to think that a position should be a pair
> (playsheet, index) or even modelled on a tree path.
>
> Any ideas?

I think the tree path is probably the best idea as abstractly thats a 
reasonable model of what the playlist would actually be like if you 
started allowing items to be expanded.

...

> Whether loading the database is noticible if *very* dependent
> on the machine you are running on.   My dually 1.8Ghz athlon
> at work doesn't seem to mind loading it.  My 466Mhz P-III
> chokes on it for 20-30 seconds everytime I opened a new browser
> (old design).   The important thing is that loading
> of metadata should not be noticable.   Let's leave the
> decisions of what should be loaded and when it should
> be loaded in the database modules themselves.  For example,
> look at the implementations of mdb/gdbmdatabase and mdb/mkdatabase
> The gdbm needs to preload the entire db in order to support
> advanced queries..  You could change with a line or two
> to cache the entries only on the first query.
>
You say that the big hit in performance was when opening a new browser. As 
far as I could ever tell the database was only loaded once, then cached. 
If this is the case then the real drop in performance was actually due to 
all the processing required to create the GTK tree (which does indeed take 
a lot of time) and didn't actually have anything at all to do with how the 
database was read from disk. You never know, perhaps the old database 
wasn't actually that slow and it was the browser that was the real problem.

David

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php