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

List:       kde-devel
Subject:    Re: Storage implementation in KDE
From:       Stefano Borini <munehiro () ferrara ! linux ! it>
Date:       2003-09-07 11:06:15
[Download RAW message or body]

On Sat, Sep 06, 2003 at 12:41:13PM -0700, David wrote:
> Someone has to categorize these files.

the user, of course, but also some metadata already present in the
inserted file, such as the id3 for mp3 or the text itself for documents
of whatever nature.

> If the user isn't already categorizing their files, a system that
> expects them to do so every time a file is created or aquired isn't
> going to help.

let the user insert keywords instead of filenames. Searching files in
this filesystem should become similar to searching with a search engine.
If there are too many matches, the ioslave should categorize them with
the other, unselected keywords, or by alphabetical index. i.e. i search
"love songs" and the system finds 600 files. Then it displays on the
screen "love songs (A)" "... (B)" etc... or better "love songs from
Artist1" "... from Artist2" etc...

About the keyword, they should be left totally arbitrary, in the way
similar to ldap. The filename is not a name, but a bunch of metadata
informations.

Problems arise to give the user the ability to understand that this
filesystem and the traditional filesystem (which is needed, at least at
the system level) are different and behave in a very different way.

> I think a better way to approach this is mapping a filesystem API on top 
> of a traditional database.A dbfs in other words. The latter has the 
> advantage of categorizing your mp3 collection without being intrusive.
> It could also be compatible with storage, should that be necessary. 

i'm strongly for this approach, and since i have a deep study of
postgres features i propose myself as a contributor if help is needed. 

> (heck, what we really need are OS/2 HPFS metadata attributes).

i have no infos about this, since i've never experienced OS2. can you
provide some link ?



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