[PhotoFloat] Tagging instead of albums

[martin f krafft]

also sprach Jason A. Donenfeld <Jasonatzx2c4.com> [2015-01-20 01:00 +0100]:
> Sorry for my rather rude response.

Sorry for my snide follow-up.

For the record, I would like to say that I agree with everyone else
that simplicity is beauty. I really do like photofloat's approach
too, and I've been a militant fan of the Unix philosophy for over 20
years now. I understand that the concept of tagging is non-Unix
(FFS!) and hence would require complexity to address, but I also
think that there are small steps in Unix-spirit that we could take
to get closer to the concept.

I am also aware that this is an open-source project and could be
forked. However, in my 19 years as Debian contributor, I have
learnt that consolidating with upstream is always better…

So let's turn this back on-topic, if you'll let me…

> This [filesystem tagging] is actually something I've given some
> thought to in other contexts --

I fully agree with you and I've ventured into this domain countless
times myself.¹ Sadly but truly, there are no easy ways that don't
involve external state and then things just get messy. Notably, the
problem is not representing/storing the tags (POSIX attributes…
etc.), but dynamic querying and viewing the filesystem for them.
It's mind-baffling to me that we are in the year 2015 and Linux VFS
has not grown this feature.

¹) e.g. http://madduck.net/blog/2007.07.24:a-user-space-filesystem-for-mail-labeling/

So, symlink farms — essentially pre-rendered tagging views — are the
best we have, and git-annex views actually manage those for you
nicely (if you don't care about the actual filenames used, and if
you're willing to jump through hoops on updates:
https://bugs.debian.org/743820).

But two problems do remain specifically to photofloat:

  1. if a given image has 6 tags and thus appears in 6 views,
     photofloat will create 6 sets of thumbnails, which is both
     a waste of CPU and disk;

  2. it's still a UI problem, as for n tags, one needs 2^n albums
     and that makes finding the album for any given set of tags
     a nightmare.

I don't really have an easy solution to the latter if the tagging
views are pre-rendered and hence the set of tags is not available to
the UI.

However, problem (1) is easily addressed with a new
filename-generation function, i.e. instead of
subdir_filename_75ps.jpg, one computes the sha1sum of the image file
and caches the thumbnails using the hash: da39…709_75ps.jpg. Now, if
two or more symlinks all reference the same file (content), they'll
all map to the same cache space and hence storage and computational
power are reduced to what's actually needed, plus the hash
computations, but those are pretty cheap.

> Email, however, evades me; I want tags/labels with emails. And yet
> as hard as I try, I fail to design an on-disk format or filesystem
> layout that cleanly maps "tags" back to a sane easy to understand
> resilient format. Everything becomes too messy too fast.

Ftr, over at http://lists.madduck.net/listinfo/mailtags, we
discussed ideas about a Git-based mail storage backend (actually
replacing IMAP!) about 5 years ago. I'd love to revive this at some
point, especially given the learnings from git-annex.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"there's someone in my head but it's not me."
                        -- pink floyd, the dark side of the moon, 1972
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1107 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.zx2c4.com/pipermail/photofloat/attachments/20150121/5bd44f64/attachment.asc>