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

List:       kde-devel
Subject:    Re: Integrating this behavior into konqueror? (again)
From:       Maurizio Colucci <seguso.forever () tin ! it>
Date:       2004-01-08 22:31:22
Message-ID: 200401082326.04428.seguso.forever () tin ! it
[Download RAW message or body]


Hello Dominic, 

your feedback is always much appreciated. :-)

> I agree completely. I think you are making a circular argument: Don't
> promote folders because they require too much maintenance.

I don't promote folders not because they require too much maintenance, but 
because I promote metadata, which require the same maintenance but have some 
advantages over folders, and no disadvantages.

> Require everyone  
> to maintain their own metadata instead, and twice, since they already have
> it anyway.

it will be easy to assign given metadata to all files in a given folder, so 
there is no added overhead if you already have well arranged folders.

> > 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. 

This will be done. But what metadata are we talking about? The metadata STORED 
IN THE FILE (mp3 and I don't know what else), or the metadata stored IN THE 
FILE SYSTEM?

> 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.

no, no... I repeat: segusoLand will import and export metadata transparently 
to and from the file system. BUT it will ask which metadata you want to 
import, because someone (like me) does not want to use metadata created by 
others, since they don't adhere to my naming conventions.


I fyou decide to import metadata embedded in mp3, this means that when you 
change view you'll be presented with a list such as


> > book
> > music
> > very good
> > Elvis
> > E. Prestley
> > Elvis Presley
> > Elvis Prestley
> > The King
> > Elvis (author)
> > By elvis

and you'll have to manually tell segusoLand which metadata have the same 
meaning, and actually merge them into one. 

For example, you have to tell segusoLand "the metadata Elvis and E.Presley 
have the same meaning, merge them into a single metadata called Elvis"

This is inevitable.

> 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)


Actually, dynamic narrowing is done based on the current selection, not on 
metadata. Static narrowing (change-view) is based on metadata, as you say 
now:

> 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.

More than that :-)

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