[KimDaBa] Proposal for branch project

[jedd]

 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
 belongs anyway?

 ] 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
 later on.

 ] 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
 worries about).

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

 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.

 Cheers,
 Jedd.