[KPhotoAlbum] Breaking changes in file layout

[Tobias Leupold]

> Maybe a good middle ground would be to keep the full file name without
> escaping, but strip the home directory if applicable.
>
> Advantages:
> + short names on average (e.g. ~/.cache/kphotoalbum/Pictures)
> + no escaping involved
>
> Disadvantages:
> + still not 100% scriptable for unusual paths (i.e. paths outside $HOME)
> + potentially deep directory structure

How about a completely different approach?

What about giving the collection a name? When it's created, a name is added
(and stored in index.xml), the default one is the directory name in which
index.xml resides. And we refer to the collection using this name, which then
has be unique. We can keep a list of used collections in ~/.whatever.

Thinking ahead, some identifier for the collection would not be bad a all:
What about somebody having the photos in ~/Photos, and deciding it would be
nicer to have it on a NAS? He moves it to /nas/shared/Photos, and the link to
the local storage is lost, although it's still the same data, only the path
was changed. The caches are now dead data and re-created.

Why don't we create something like an uuid, place it into index.xml and refer
to the data using it? For scripting, it's clear where the data points, and one
can extract the id before querying something. And it would be robust
considering path changes.

Let's simply have a new block called "<metadata>" or such and add
"<collectionId>whatever</collectionId>". Or maybe better "<meta
name='collectionId' value='whatever'/>". Or such.

> > Should it be part of the index.xml file proper?
>
> I'm not a big fan of CDATA sections in XML files. Moving the files into
> index.xml would create more problems than it solves: I like my index.xml
> file easily editable by hand and diffable. Also, I don't want to deal with
> the files during database-load and keep them in memory for later.

I also would not store masked binary data in index.xml. It's already big
enough, and I see the complete transparency of the file and the fact it's
easily editable as an outstanding feature of KPA (that actually was the real
reason I chose it back then!). Having binary blobs in it would be odd.

The directory structure and esp. the file names should be reworked. But I
would keep the files as files.

Another proposal: If we do breaking changes to all this, maybe we should move
all files we create in one subdirectory of the collection. I personally would
create a directory called "KPhotoAlbumData" or such, and let everything happen
inside. This way, it's clear for the user that everything inside this
directory is KPA-generated and everything outside is not.

What do you think?