[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Integrating this behavior into konqueror? (again)
From:       Dominic Chambers <dominic () enkasa ! com>
Date:       2004-01-08 21:49:58
Message-ID: 200401082249.58913.dominic () enkasa ! com
[Download RAW message or body]

> > Why do you need to assign metadata yourself? In the case here, the
> > music files already have metadata embedded within them. It should be
> > able to read that meta data out (in the file I've looked at, the pop up
> > info KDE gives includes title, album and artist) and provide options
> > based on that.
> >
> > If the user has to sort this out themselves, they won't.
>

I agree completely. I think you are making a circular argument: Don't promote 
folders because they require too much maintenance. Require everyone to 
maintain their own metadata instead, and twice, since they already have it 
anyway.

> Because everybody has his own conventions: if you use the metadata embedded
> in the mp3 by other people who created the file, you will end up with a
> bunch of equivalent metadata:
>

This means that the user should change the metadata at it's original location, 
possibly with the help of segusoland. You are going to require that users 
build and maintain their metadata twice. This is such a bad idea I just can't 
understand why you would even consider it.

If you have ever had to maintain two similar databases you will know that 
keeping everything synchronized is a major headache. It's not just the work; 
you will make it so that no KDE apps can benefit from the data that the user 
provides through segusoland, and segusoland can not benefit from the data 
that is provided by the KDE apps. You are essentially creating an iron 
curtain to divide the desktop.

> Elvis
> E. Prestley
> Elvis Presley
> Elvis Prestley
> The King
> Elvis (author)
> By elvis
>
>
> Frankly, I don't want to see other people's metadata.
> Furthermore, I don't understand if we are talking about metadata in mp3
> files, or metadata in reiser4/ext3.
>
> Anyway, I will add an option to import the metadata present in mp3 files...
>

This is only my opinion, but I think you should look at this subject a little 
more holistically, rather than adding a quick hack for MP3s. It would appear 
to me that segusoland has two major functions, both requiring metadata -- to 
the extent that the success of the program is a function of the quality of 
the metadata available. These are:

1. Allow intelligent options and option narrowing based on the metadata 
available for programs and devices (context intelligence/option narrowing)
2. Allow file location and viewing based on the metadata available for those 
files, rather than their location (location transparency)

I would say that at the moment you have a strong 'context intelligence' 
candidate, but weak 'location transparency'.

As always, just my two pence.

> Maurizio
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]