Re: XML Tree in MusicBrowser

On Thu, 07 Apr 2005 23:13:41 +0100, kristian kvilekval <[email protected]>=
 =20
wrote:

>
> Hi David,
>
>    I finally got a chance to try out your new stuff.
> I think it's really cool that you've got this working.
>
> I've got a couple of comments/questions.
>
> 1.  I think treemetadata is great..
> 1a. You should define string constants for all your
>     default strings (maybe in a toplevel file) i.e.
>     const std::string kTrue =3D "1"
>     which will help with insert and delete times.

Will try and look into it this weekend.

> 2.  I also like musiclistings, but am wondering if
>     we can provide the functionality in a single
>     hierarchy.  For example mbcd and filemetadata
>     could be improved to provide the readEntries function
>     for urls that each of the modules can parse.
>     mbcd would take on expanding cd urls and filemetadata
>     would do the playlist urls.

Sounds reasonable, I'd forgoten about mbcd when I created the cdlisting =20
class. I think we might want to rename filemetadatadb to filedatadb if we=
 =20
do this though, as the contents of a playlist arn't really the files =20
metadata but it actual data, and file tags could be classed as either =20
metadata or data (in my opinion anyway :)).

I do think however, the listing and metadata lookup interfaces should be =
=20
seperate yet combinable. This would mean you could have listing classes =20
that don't deal with metadata and vice-versa, although in most cases the =
=20
same class would implement both these interfaces.

> 3.  It seems an opportune moment to try to integrate
>     cachedb which should speed things up considerably.
>     I am not sure if it was implemented correctly, but
>     the idea was that once a deep metadata search had
>     been performed, each metadata provider layer would be
>     given the chance to update its metadata.  In fact,
>     the code is commented out at the
>      bottom of  MetadataPath::ReadMetadata
>
> Metadata direction
> ^   cachedb
> |   treedb
> |   local  (metakitdb)
> |   pathdb
> |   tags
> |   musicbrainsdb
>
>    The diagram does not include priorities assign which metadata
>    can overwriten from a deeper source.
>
>    We would also need an option of last resort so that missing
>    metadata field would be filled in with defaults such that most
>    queries will be satisfied with a hit from cachedb after at most
>    1 deep search.
>
>    Finally we need something to let us know when the cached entry
>    is invalid.  Seems like I started something and never finished with
>    the routine time_t MetadataDB::modified (const url_t&)
>    I see these options:
>    1.  Ignore it, valid for run of program
>    2.  Test source for change.  i.e. time on usr)
>
> I'll try and to see if I can get this code functioning
> based on your tree and let you know..
>
> Nice work,
> kris

That would be great if you can do it. It is definetly something worth =20
attempting.

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


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick