Re: xmltree and mdb

I've updated my archive with a some new search stuff
which takes care of the problem outlined below.
Combined with the patches from dave's archive
the browser seems downright speedy.



On Mon, 2005-05-23 at 14:24 -0700, kristian kvilekval wrote:
> Yes, I see your point.. I didn't try it on directories.
> 
> We need a way to know that the cache is incomplete and
> therefore other sources should be searched again for 
> the incomplete tags.  The cache should also be a union
> of queries instead of simply a cache of the last query.
> 
> I had thought of time stamping the keys.  The first time 
> a key is searched on the timestamp would be 0, and after that
> the timestamp would come from the winning metadata source.
> However, I didn't want to add the complexity.  Another
> way would be to allow searches based on the original algorithm:
> look at all the sources until the set of keys is fulfilled
> combined with a good default meta datasource (fill all unknown keys
> with a default value).
> 
> I'll look into it.
> 
> 
> On Mon, 2005-05-23 at 21:57 +0100, David Hough wrote:
> > On Fri, 20 May 2005 20:58:38 +0100, kristian kvilekval <[email protected]>  
> > wrote:
> > >
> > > I've added checks to make sure we don't search data sources
> > > that have not been updated since the last time we cached.
> > >
> > ...
> > >
> > > Kris
> > 
> > I've just been playing around with this, and I've come across a  
> > potentionally serious problem. Effectively the metadata tags requested for  
> > a particular url the first time a request on that url is made, are the  
> > only ones that can be looked up if others weren't found while looking for  
> > them.
> > For example, if you are browsing a directory in the tree that contains a  
> > subdirectory of music, and you double click the sub dir without opening  
> > it, the tracks appear blank on the playlist.
> > 
> > This is becasuse the tree does a request for expandable;playable tags on  
> > each track first to check if they should be added to the playlist. MusicDb  
> > will then search Cache->MkDatabase->TreeDb and store the  
> > expandable;playable metadata in the cache. (Note: I'm assuming the tracks  
> > aren't in MkDatabase).
> > 
> > When the playlist then searchs for title;album;... the MusicDb searchs the  
> > Cache and gets a response. However, it then doesn't search any of the  
> > other sources as they're all older then the cache, so title;album;... is  
> > never found.
> > 
> > Basically, it's assuming that newer sources always have all the metadata  
> >  from all the older sources which isn't always true.
> > 
> > Unfortunatly, I'm at a loss on how to solve this if we don't store a list  
> > of sources that we're searched to generate the cache. Any ideas?
> > 
> > Cheers,
> > David
-- 
Kristian Kvilekval
[email protected]  http://www.cs.ucsb.edu/~kris w:805-893-2526 h:504-9756



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20