https://bugs.kde.org/show_bug.cgi?id=258272Ilia K. <
[hidden email]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |
[hidden email]
--- 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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Locked
