[KPhotoAlbum] Fwd: Re: Breaking changes in file layout

[Tobias Leupold]

I think this was intended to go to the list:

----------  Weitergeleitete Nachricht  ----------

Betreff: Re: [KPhotoAlbum] Breaking changes in file layout
Datum: Dienstag, 7. April 2020, 21:46:34 CEST
Von: Andreas Schleth <schleth_es at web.de>
An: Tobias Leupold <tobias.leupold at gmx.de>

Hi Tobias,

Am 07.04.20 um 10:25 schrieb 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.

Right now, everything, except the kphotoalbumrc file are within the same
tree. Moving this tree around in toto does not change a bit. I even can
access a database directly on my backup disk with KPA.

Dividing the data to different locations (images & index.xml & databases
here and thumbnails there) does not improve handling (as in backup or so).

I have all my data on a NAS and do not have performance issues *viewing*
the (video)thumbnails. Creating them takes time because reading the
images and videos over Ethernet is slow. But I pay only once.

I also understand Harald's approach, because he could even view his
thumbnails without a network connection. Same as with missing images.
So, that approach would make it feasible to have the images in the cloud
... If you had a remote thumbnail generator floating around with the images.

>
> 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.
Yes, Yes, Yes!
> 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?

This would make things at least a bit more fool proof.

Cheers, Andreas

-------------------------------------------------------------