[KimDaBa] another feature request
ekj at zet.no
Fri May 6 17:48:42 CEST 2005
On Friday 06 May 2005 12:45, Martin Höller wrote:
> I'm afraid, you didn't get what i mean. Is my English that weird? ;-)
> Let me try again.
Dunno, I'm Norwegian, to me it made perfect sense. That migth be because my
englisch understanding is correspondingly weird though :-)
> What I want to do is burn part of my images to a CD and remove them from
> disk. Therefore any kind of links wouldn't help me in any way here.
> Am I the only one who wants to save images on a CD, remove them from
> disk but keep the thumbnails? Or am I just missing something?
I don't think so. And furthermore, this is really just a subset of the
people having (or wanting) a read-only image-directory.
At work we've hacked it with symlinks (pointing the xml-file aswell as
every thumbnail-directory to files/directories under $HOME/.kimdaba/ but
it's a hack.
I would *really* like to see an option for Kimdaba, something like: "store
thumbnails and data under $PATH where $PATH defaults to the image-dir,
which would give the same behaviour as today, but could be changed to
something else by people with that need.
For example, at work we've got a large image-database. It is *VERBOTEN* to
change, in any way, images stored there. We ensure this in practice by
having it exported read-only from a NFS-server. It is however allowed to
change the tagging of the images, infact several different people are
allowed to do this. We've fixed that by symlinking the xml-file to a file
on a read-write file-server where the people with tagging-permission are
members of a group with read-write on the xml-file, whereas all others
have only read on the xml-file too.
> Do you think people do this? I have all my images in /home/martin/fotos/
> where /home is on one filesystem.
We do this. Infact the images are on a completely separate fileserver.
> But even if they do, what could be the reason for this? Maybe because
> part of their images are on a removable device. If this is the case they
> could prefer to have the thumbnails available even if the removable
> device is not mounted.
Images are read-only. Tagging-data and thumbnails are not. Kimdaba supports
this paradigm very well, by refraining from messing with the images
xml-file is in $PICROOT/index.xml
thumbnail for $PICROOT/$PICDIR/$IMAGE is in
How about making this configurable ? All one would need to do would be to
add a $CONFIGROOT that defaults to $PICROOT then the xml-file would go in:
$CONFIGROOT/index.xml and the Thumbnails in $CONFIGROOT/$PICDIR/$IMAGE
Changing $CONFIGROOT to say $HOME/.kimdaba would allow kimdaba to work
perfectly with a read-only $PICROOT.
(yeah, I am fully aware Kimdaba ain't programmed in shell.)
I realise I should prompt my boss into paying for this by the way :-)
More information about the KimDaBa