[KimDaBa] another feature request

[Eivind]

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

Suggestion:


Currently:

xml-file is in $PICROOT/index.xml

thumbnail for $PICROOT/$PICDIR/$IMAGE is in 
$PICROOT/$PICDIR/Thumbnails/$IMAGE 

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 :-)


	Eivind Kjørstad