From: 5srmspw02@sneakemail.com (Guarded Identity)
Subject: [sup-talk] New User Questions
Date: Wed, 26 Mar 2008 00:57:05 -0500 [thread overview]
Message-ID: <13352-37236@sneakemail.com> (raw)
In-Reply-To: <1199944172-sup-660@south>
Hi,
I've been using Sup for a few months now, read up a little more on Ruby, and
thought I might be in more of a position to respond to this thread.
Excerpts from William Morgan's message of Thu Jan 10 00:34:03 -0600 2008:
> Excerpts from Guarded Identity's message of Tue Jan 08 19:39:18 -0800 2008:
> > Will migration of maildir mail from new/ to cur/ necessitate an execution
> > of sup-sync?
>
> Hm. I don't think so. As long as the mtime and size of the file are
> preserved (which I believe they are during a move) you should be ok.
I was thinking about the algorithm for calculating the message's unique
"source_info" for Maildir mail (mtime appended to filesize). I know altering
the backend might really be something you don't want to support, so maybe I'm
voicing a moot concern. It's just that sometimes I get annoyed at people
sending me mail with large attachments (especially at work where I just can't
control this kind of thing too well). In the past, I'd use mutt to purge mail
of their large attachments.
However, I guess if I do this en mass, I loose my labeling of these messages
when I do a sup-sync because the message's source_info changes, right?, but
have you considered using a message's "Message-Id" header as part of the
source_info? I'm thinking you might have. For the most part, this should be
pretty unique, right? I know the Message-Id is sometimes missing, but we can
default to the old source_id if things are really wacky (which should be
rarely, right?). The only reason I could think you wouldn't use the Message-Id
is because maybe it's less efficient to open up a message than look at it's
file stats. Or maybe there's another reason?
> > I had done this before, actually, but I noticed that Sup indexing was
> > slowed down quite a bit (rss2email and mailing lists generate a lot of new
> > mail).
>
> If that's true, then it must be due to IMAP transmission costs. I'm
> certainly willing to believe that pulling a message from IMAP is
> significantly slower than a disk read.
I was thinking about this too. Is there anything we can do to pull down
headers first to fill the index (backgrounding the indexing)? Maybe that might
make the delay with IMAP less of a nuisance?
However, I won't harp on this too much. Because I wasn't comfortable
synchronizing (say with Unison) sup Ferret indexes across hosts, I'm ssh'ing
into the machine with the index and using "maildir" sources. But this
unfortunately causes me a problem with viewing graphical attachments because X
forwarding is really slow. So for now I'm saving attachments and scp'ing them
over. I'm not sure there's much anyone can do about any of this.
> > I would really like to have time-based auto-expiry (excluding starred or
> > special-labeled items) for some of my mail (primarily mailing lists and rss
> > feeds). With mboxes, I guess I could do some "deleted"-labeling with a Ruby
> > script followed by a call to sup-sync-back.
>
> That sounds like the right approach.
>
> > 6. What are my scripting options for mail expiry with Maildirs? The search
> > to get the message objects is pretty straight forward. How much further
> > work is it to delete the message from the index and to get a filename of
> > the message to delete from the maildir?
>
> Trivial, although the filename/IMAP id require minor API changes to expose
> those functions. But with a working sup-sync-back that applies to all source
> types, you won't have to do anything other than inject :deleted labels
> everywhere and simply call sup-sync-back.
Okay,
So I've been using a helper script that does some things to help me manage my
Maildir mail (all other source types are ignored). My primary idea was to have
a script to expire mail, but allowing me to save threads labeled "starred" or
"save". Eventually I added in a function to manipulate labels. Unlike
sup-tweak-labels, this script gathers it's pool of messages from the index
using a Ferret query (Chronic allowed) rather than using source URIs.
I got around some of the encapsulation inherent in the API by just brute force
breaking encapsulation (which Ruby makes kind of ridiculously easy it seems).
I've attached the script, and would like to see any feedback if people have
some. In particular, I'm eager to know of any concerns people have with the
approach or defects people catch. I'm still pretty new to Ruby, so if I did
anything flat out stupid with the language, please let me know.
By the way, I was thinking that there seems to be a good deal of healthy
participation in this list. Does anybody see any value to hanging out in #sup
on Freenode? Sometimes it's just nice to have an IRC forum.
-Sukant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sup-tweak-maildir
Type: application/octet-stream
Size: 6652 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/sup-talk/attachments/20080326/cef1c568/attachment.obj
next prev parent reply other threads:[~2008-03-26 5:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-09 3:39 Guarded Identity
2008-01-10 6:34 ` William Morgan
2008-03-26 5:57 ` Guarded Identity [this message]
2008-03-28 0:22 Marc Hartstein
2008-03-28 10:33 ` Marcus Williams
2008-03-28 11:24 ` vasudeva
2008-03-28 17:23 ` Marc Hartstein
2008-03-28 19:51 ` Marcus Williams
2009-02-26 17:33 [sup-talk] New user questions Vadim Gutnik
2009-03-22 17:30 ` William Morgan
2009-03-22 17:56 ` John Bent
2009-03-22 19:22 ` William Morgan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13352-37236@sneakemail.com \
--to=5srmspw02@sneakemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox