Very true but it begs the question of generic picture management policy.

Posted Jun 28, 2010 20:53 UTC (Mon) by bjartur (guest, #67801)
In reply to: Very true but it begs the question of generic picture management policy. by tzafrir
Parent article: A quick grumpy review of Shotwell

It's a simple tradeoff:

use the "right" solution (xattrs): Metadata will persist through changes and reorganization; Other programs will be able to find and use metadata (file managers, (set|get)fattr).; Not all filesystems support xattrs. Some hacks exist to store xattrs in filesystems that don't support them but do support some similiar concepts (e.g. NTFS alt.str.).
use the "hacked" solution (seperate metadata files): Will work over e.g. NFS sans extra hacking; Metadate won't persist through edits and reorganization. Hacks exists to make metadata persist through either (e.g. by comparing images to all existing images).; Metadata won't be obviously "attached" to the related files.; Directories get cluttered with metadata files or risk corruption of metadata of all imported files.

Personally, I'm a fan of xattrs as I like being able to move the files around without having to fire up a specific image-moving application and glancing over the images themselves rather than just telling sh to move all images taken in a certain timespan to a seperate folder and consider storing images in big library that makes exporting images to native filesystems necessary plain aweful.

Very true but it begs the question of generic picture management policy.

Posted Jun 29, 2010 11:22 UTC (Tue) by paulj (subscriber, #341) [Link] (7 responses)

Why not develop a file format that can handle multiple streams internally? Then you get the best of all worlds:

- works with tools which think files are just files
- allows other tools to treat files as collections of different data

There are a number of such formats already, what we're lacking is a format that is optimised for multiple-streams for data storage.

Very true but it begs the question of generic picture management policy.

Posted Jun 29, 2010 16:41 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

Wouldn't we call these multiple-stream files 'directories'?

Very true but it begs the question of generic picture management policy.

Posted Jun 29, 2010 17:45 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

Yep, but that's fragile in the face of applications that are not aware that the dirs+files are arranged in certain way - leading to the problems the parent poster perceives which caused them to argue for xattrs (which are much, much more fragile in the same sense - and hence much worse).

Very true but it begs the question of generic picture management policy.

Posted Jun 29, 2010 20:03 UTC (Tue) by nix (subscriber, #2304) [Link]

FUSE (automounted by a library) plus something like tarballs (only not actually .tar, I know .tar is vile, maybe .gz.cpio, i.e. gzipped first then cpioed?) might do the trick.

Very true but it begs the question of generic picture management policy.

Posted Jun 29, 2010 18:15 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

you mean like EXIF tags inside a image file?

Very true but it begs the question of generic picture management policy.

Posted Jun 30, 2010 6:59 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Yes. Is EXIF limited in some way though, that makes it less than useful for image apps to put all their metadata in there?

Very true but it begs the question of generic picture management policy.

Posted Jun 30, 2010 7:19 UTC (Wed) by dlang (guest, #313) [Link]

probably the fact that it's fairly expensive to search metadata that's part of many separate files compared to having the data condensed into one file/database

this applies to xattr use as well.

Very true but it begs the question of generic picture management policy.

Posted Jul 4, 2010 18:21 UTC (Sun) by bjartur (guest, #67801) [Link]

It's called "filesystem" :P

Ideally, I'd like simply having mountable files (on Linux you'll need a loop device; preferably in user space) that can be formatted as a directory (multiple named internal data streams), list (multiple indexable streams) or whatever may be invented in the future. Simple bencode some data and mount it to be able to work with it The Unix(R) Way. The tools that work with the data need not care how it's stored on disk, so you can just choose the most efficient format or whatever suits you.