[KimDaBa] Proposal for branch project
jedd at progsoc.org
Sun Mar 28 01:10:17 CET 2004
So long as others are happy for this to be on the list. It's
bordering on off-topic (okay okay, it's way off topic) but
it's related to the broader topic, perhaps, depending how
loosely you're happy to define ... yada yada.
On Sat March 27 2004 11:24 pm, David Fraser wrote:
] Others have commented that this belongs in the filesystem.
] But a lot of those comments could apply to KImdaba itself.
You're possibly talking about me there. I'm not sure which comments
could apply equally well to KimDaBa, but I'm always more than happy
to comment on things.
] My view of it is, maybe it does in the long run, but its not there now,
] so why not make something now rather than waiting for the file system?
So you have two beliefs:
1. That it probably belongs in the fs, and
2. That regardless of where, effort needs to be applied to create it.
So the question can be turned on it's head - why spend effort duplicating
many very similar applications when a smaller effort could be spent on
developing a single integrated solution, and in the place where it probably
] I see KimDaBa as a way to browse & categorise information (in this case
] images) - its a user interface to that process.
It's a database. With a very nice front end. (Despite the Thumbnails. ;)
] Whether the actual metadata is stored in an index file like KimDaBa does
] it or in a special place in the file system isn't that important -
Actually that's a very important thing to consider, but we'll get to why
] Kimdaba could easily be adapted to work on file system metadata, and so
] could any broader system. What's important (and brilliant about KimDaBa)
] is the ease of use etc.
Very much so. I haven't looked at the source much, so can't begin to
estimate what the %-breakdown is of the read/write-the-xml, the UI
proper, the database logic, etc is .. but it seems to me that the UI and
the logic would be the big things, and that it would be a relatively
trivial task to change the application to use something other than a
flat-file - say postgresql, or a plug-in to a file-system.
] Anyway the main aspect of KImdaba that wouldn't work easily for
] non-images is previewing thumbnails.
KDE currently thumbnails audio quite acceptably (though I hate it),
and thumbnails video files quite nicely (though the first frame of many
videos is black), I think.
Without thumbnails, though, it becomes very tricky to categorize the
data files in the first place. It's easy with KimDaBa because you can
see who's in the photo, where that shot was taken, etc. With a text
file this is uber-painful (and as I mentioned before is best handled
by things like htdig). With a video file it's probably even more painful.
With audio files it's anywhere between slightly and very painful.
] But there's a whole lot of stuff that is relevant and could be applied.
Creating arbitrary attributes to files and having arbitrary values assigned
to those attributes, and having a nice UI to assign and query those values?
At the end of the day, if that's what you're after then all you're after is
a database with a data-input screen and a query engine.
] I think, rather than writing a whole lot of different apps (Images,
] Sound, Text, etc) it would be cool to have one app that would handle a
] variety of media types, and use the same categorisation system for all
] of them.
When you say categorisation system, what are you referring to? The
ability to create arbitrary attributes, or having the same attributes assigned
to all file types (person, location, keyword). If the latter, how does that
work for different media types (audio, av, image)?
] In addition, it would be cool to be able to share that
] information - I was wondering about using PyImdaba to make a web-based
] browsing system.
] If something like this handled not just images but sound, text, etc, it
] could become a kind of multimedia-meta-blogging system.
Ahh yes. What the world needs now is more blogging systems. ;)
Writing front-ends specific for web-based browsing systems is another
example of how this approach commits you to extra work just to get the
different user-level 'components' talking to the same language.
If you want to have different attributes for different types of files, then
there's suddenly no reason to have them all contained in the same database
(xml file, say). You end up with either different apps designed to enter
data & do queries on different file types, or you end up with something
so generic that it looks like every other database interface (this isn't a
necessarily bad thing, IMO). And you end up with lots of xml files in
various places that you have to carefully track (or one that contains all
your disparate data and is so big that you'd have data-corruption & recovery
Consider that once this information is plugged in to the file system, you
get a number of benefits.
First, your application doesn't have to worry about exporting or importing
(merging) data from other sources. You just copy bits of the file-system
around. You get transportability.
Second, you get a performance benefit - file-system plugins are going to
be faster than flat-file databases running in userspace.
Third, you get convenience - you don't have to code for special cases
like moving image files from one directory to another, as files and their
attributes are intrinsically connected at an OS level.
You also get lots of little benefits - you get to focus on the UI and
logic / design, and just use the FS's API to do the tedious stuff. You
attract the attention of lots of people who want similar things but don't
realise it yet. You get to deprecate the umpteen mp3-playlist-managers
on sf overnight (this is definitely a good thing).
I guess my point is that if you think the logical place for this is in the
file-system, then consider doing it properly - write a generic attribute
plug-in for reiserfs v4 that KimDaBa can then use as a backend, rather
than duplicating a bunch of code that shouldn't need to exist in the first
Actually I wouldn't be too surprised if someone isn't already working
on this kind of plug-in. There doesn't seem to be much info on plugins
in progress on the namesys site though.
More information about the KimDaBa