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]
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]
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 (✭ supporter ✭, #313)
[Link]
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]
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 (✭ supporter ✭, #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.