On Tuesday, August 8 at 06:21 PM, quoth Rocco Rutte:
If you can fetch the UID and the flags from the IMAP server, I think you should be able to reconstruct the filename ("UID:2,FLAGS"), provided you can prevent people from modifying the filename on their own time.Yepp, modification outside of mutt is the main problem. Note that mutt does manage the flags internaly regardless of the cache filename. The modification of the cache filename is only bad because you can't find it and will download it again.
Assuming that you don't do the equivalent of this:
filename="$IMAP_UID:2,S"
if [ -f $filename ] ; then
readit
else
filename=`ls $IMAP_UID:2,*`
readit
fi
Which would slow down if and only if people are mucking with your
cache underneath you. And since we can make it clear that mucking with
the cache while using it as a cache is BAD, slowing it down only in
that case isn't too bad.
IMHO this leads to nothing being rock-stable against modifications so that "ordinary" users can start viewing it.
Why can't we simply twiddle the read/write bit on the directory so that "ordinary" users *can't* modify it?
So, the problem with something like an mh folder is storage of flags (I think), because they store flags in an X-Status: header much like an mbox (if memory serves). This should be easily solved by simply setting messages stored there to be read-only, shouldn't they?Yeah, but then the locally cached message is different from the local one. Think of somebody adding the X-Status header in the local cache and viewing the message from another client with all headers. They will differ... which is confusing.
And which is why I suggested doing a chmod() on the messages in the cache so that other viewers CANNOT add their own X-Status header to the local cache, thus solving the problem.
Well, but what about something like you suggested: symlinks. Like so:#!/bin/bash mkdir -p ./OfflineMaildir/cur mkdir -p ./OfflineMaildir/new mkdir -p ./OfflineMaildir/tmp for F in $message_cache/* ; do bname=`basename "$F"` ln -s "$F" "./OfflineMaildir/cur/$bname:2,S" done chmod -R a-r ./OfflineMaildirThis is much to complicated: #!/bin/sh mkdir -p /tmp/foo/new ln -s $message_cache/pops:.../ /tmp/b/cur
But that makes it so that a reader will modify the actual filenames, which is bad. My script separates the filenames from the message content.
and add a folder-hook setting it read-only. With your one you don't win much, IMHO.
I win the ability to view it without corrupting the cache, and the ability to view the cache with non-mutt readers (current cache filenames do not follow the Maildir spec, and as such would be ignored by a strict maildir reader).
The goal is to make it possible to view things semi-conveniently offline, not to perfectly replace actually having a network connection.Yeah, of course. But you can't view everything; just what you saw already so this isn't even a "read-only offline cache".
So? It's better than nothing. I'm not saying advertise it as "NEW! Mutt can read ALL YOUR MAIL offline!", I'm saying make it more convenient to use what we already download. I mean, if we insist that offline use of the full message bodies that we happen to have downloaded can only be done by mutt-geniuses who know the innards of the cache, you might as well just insist on using "cat" for everything. The key word in what I said was "semi-conveniently" not "perfect for all uses, cache of everything". We HAVE these messages stored on disk already, it seems a shame to be unable to use them (with anything other than "cat" or "less" or "more").
~Kyle
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer
Attachment:
pgp61N5PYOw2v.pgp
Description: PGP signature