This is a summary of the discussion here: https://mail.kdab.com/pipermail/kphotoalbum/2020-April/006572.html

Status quo

DBDIR/index.xml
DBDIR/CategoryImages/
DBDIR/layout.dat
DBDIR/exif-info.db
DBDIR/.thumbnails/
DBDIR/.videoThumbnails
XDG_DATA_DIR/kxmlgui5/kphotoalbum/kphotoalbumui.rc
XDG_CONFIG_DIR/kphotoalbumrc

This directory layout worked ok, but has some shortcomings:

• it's unclear to the user which files they can safely delete
• potential problems with DBDIR on non-local storage -> there are occasional problems with people on NFS -> SQLITE files on CIFS seem to be unsupported
• different performance requirements: -> the cache files have different access patterns than the images themselves
• sharing an image directory across different computers can lead to subtle

problems (e.g. different thumbnail size)

Proposed changes to the file layout

DBDIR/index.xml
DBDIR/CategoryImages
XDG_CACHE_DIR/kphotoalbum/<db>/exif-info.db
XDG_CACHE_DIR/kphotoalbum/<db>/thumbnails/
XDG_CACHE_DIR/kphotoalbum/<db>/videoThumbnails/
XDG_DATA_DIR/kxmlgui5/kphotoalbum/kphotoalbumui.rc
XDG_DATA_DIR/kphotoalbum/<db>/layout.dat
XDG_CONFIG_DIR/kphotoalbumrc

There are different proposals for the <db> part in some of the directories. The value is derived from the index.xml path.

1. MD5 hash of the path (e.g. ~/.cache/kphotoalbum/0ada08745b07902c10efb58eb9f1833b) → Strongly not favored by Robert, not obviously related to original path
2. Repeated path (e.g. ~/.cache/kphotoalbum/home/johannes/Pictures) → disliked by all, long paths
3. Mangled path (e.g. ~/.cache/kphotoalbum/home|johannes|Pictures) → disliked by Johannes and Tobias, long paths and yet another escaping mechanism
4. Web-like path (e.g. ~/.cache/kphotoalbum/12345-Pictures) → disliked by Johannes, yet another escaping mechanism
5. Shortened path (e.g. ~/.cache/kphotoalbum/Pictures); like proposal 2, but with the $HOME prefix removed. This deteriorates into proposal 2 for paths outside the home directory of the user. → no feedback yet
6. Introduce user-defined collection name, defaulting to the base name of the database directory (e.g. ~/.cache/kphotoalbum/Pictures) or to a UUID

Usage scenarios - pitfalls

Any solution has to be able to support the following ways to set up the database.

Image directory/database on remote storage (NFS)

This is a major reason for changing the directory structure as outlined above, and the main scenario besides local storage.
Thumbnails are on (usually fast, low-latency) local storage.

Shared remote image directory/database with local non-shared thumbnails

This scenario is a reasonably safe way of sharing the image directory between different machines and/or users.
Thumbnails are on (usually fast, low-latency) local storage in a size that is optimal for the given machine.

Shared remote image directory/database with shared remote thumbnails

Some users currently share the thumbnail data across different machines alongside the image directory.
This scenario helps users that have slower network drives, because the thumbnail data only has to be created once.
This use-case still needs to be supported. Manual setup (creating symlinks) may be required for those users.