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

List:       kde-devel
Subject:    Re: Storage implementation in KDE
From:       Brian Ledbetter <brian () shadowcom ! net>
Date:       2003-09-07 2:58:52
[Download RAW message or body]

David wrote:
> It's an interesting concept, and it should not be excluded from the KDE
> options going forward. But I seriously question its usability in
> practice. For certain filesystems or directories it may make sense
> (50,000 mp3 files), but in the general case it would provide little benefit.
> Someone has to categorize these files. 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.

This is true - though I think the point of Storage is that much of the
metadata available for categorizing files (namely, track titles, artist
names, document attributes [author/title/etc], and the like) is already
there.  No additional categorization would be required on the part of the
user.  The idea is intriguing, though - I'll see if I can come up with a
proof-of-concept modelled after what Seth already has done.

> 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.
> (heck, what we really need are OS/2 HPFS metadata attributes).

FreeBSD offers this.  While it's certainly useful to have a "resource fork"
(in the Macintosh parlance), I don't know if this really adds anything that
some sort of index file or simple database couldn't add.

-- 
Brian C. Ledbetter <brian@shadowcom.net>
http://www.shadowcom.net/brian/
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]