[Digikam-devel] [Bug 258272] Export album properties for compatibility with simple image viewers and archiving

[Ilia K.]

https://bugs.kde.org/show_bug.cgi?id=258272


Ilia K. <mail4ilia at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mail4ilia at gmail.com




--- Comment #1 from Ilia K. <mail4ilia gmail com>  2011-05-02 01:09:48 ---
Another possible solution is to write album metadata to *each* file inside the
album. I'm not aware of standard metadata fields for such info, but
digikam-specific metadata can be used for this. Of course, users which don't
need this feature should be able to opt-out of metadata synchronization to
files.

Pros:
- all album metadata is available as long as any file from it is available
- when file is sent somewhere album metadata travels with it
- low-level metadata handling is already implemented. Moreover, with a little
  effort all album metadata can be treated as a special tag, so most of the
  code can be reused.

Cons:
- metadata duplication takes an additional space.
  Anybody cares about this? Seems to be negligible.
- synchronization issues between file's metadata and digikam's one.
  This is quite similar to current tags DB<->files synchronization
- digikam supports album hierarchy, so A/B/C/file.jpg would need to handle
  information about A, B & C
- conflict detection and resolution:
  What should be done when a file is moved between albums outside digikam?
  Detection is the same as for any new files. Conflict can be solved by 
  asking a user whether he wants to rewrite file's metadata or to move file
  (back) to appropriate album, probably creating the album if it's absent.
- time overhead:
  1. File's metadata conflict detection is needed for files added/changed
     outside digikam. File hash and/or mtime/ctime stored in a DB can 
     considerably speed things up.
  2. File's metadata update can be lengthy, when a lot of files updated.
     This is the only real drawback of this scheme, as I see it.
     Some background updater can be implemented to compensate for it,
     but this doesn't seem to be as trivial as just letting the user wait...

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.