From: wmorgan-sup@masanjin.net (William Morgan)
Subject: [sup-talk] New User Questions
Date: Wed, 09 Jan 2008 22:34:03 -0800 [thread overview]
Message-ID: <1199944172-sup-660@south> (raw)
In-Reply-To: <29393-78803@sneakemail.com>
Excerpts from Guarded Identity's message of Tue Jan 08 19:39:18 -0800 2008:
> I know Sup has room for more features and functionality, but it my
> mind, it's no where near sucking, especially with the option of using
> sup-console or Ruby scripts using Redwood libraries.
Thanks! Always nice to hear.
> 1. Can sent mail only be stored in an mbox, or are other formats
> supported?
Right now it's mbox only. There's no technical reason it couldn't be
stored in a Maildir, it's just that writing to an mbox is just the
easiest possible thing in the world.
> 2. 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.
> 3. If the filename of maildir mail changes, is a sup-sync required?
No, for the same reason.
> If 2. or 3. are indeed problems, maybe I could front the maildir
> sources with an IMAP server. 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.
> 4. How far away is sup-sync-back support for maildirs or IMAP? Is the
> work straight-forward or are there some technical kinks to be ironed
> out?
The actual interactions with the sources themselves should be pretty
easy, because they both support deleting individual messages directly.
Mbox was actually the hard one, because you have to rewrite the entire
file to delete messages.
But ideally sup-sync-back would be source type agnostic, so there's some
work to be done in terms of adding deletability to the source API in
such a manner that it handles both the mbox case and the not-mbox case.
(Mbox deletions need to happen in one go, whereas not-mbox deletions can
happen one at a time.)
> 5. Should I consider using mboxes for any reason beyond support by
> sup-sync-back?
No. Mbox are a terrible, evil format that just happens to be
well-supported by Sup.
> Also, 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.
> 7. Any proposal for easily opening urls from messages?
>
> urlview is already coded up, so I'm all for a mechanism for piping
> messages into an external application. But this leads to other design
> issues, I think, like how to enable user-level key bindings.
I'm not familiar with urlview. If it is a console-based interactive
program, it should be possible to just spawn it via the hooks. We may
have to add a hook, depending on the exact usage case here.
> 8. I'm a little confused about threading interacts with labeling in
> Sup. Labels are applied to entire threads, but it seems that labels
> are stored on a per-mail basis.
Correct. But you never really get to play directly with message-level
labels in Sup, except for a few little things like starring and unread
status, which can be applied per message in thread-view-mode.
> Is seems possible for message within a thread to have different
> labels, say by using a before-add-message.rb hook. Is the label set
> for the thread a union of all the labels of its constituents?
Correct.
> 9. If a new message comes into a thread, is it auto-labeled with the
> labels of the thread?
No.
> 10. I tried to do some auto-archiving with the before-add-message.rb
> hook using message.remove_label("inbox"), but it didn't work. Is this
> possible? Or is auto-archiving only possible at the source level?
That should work. If you post your hook we can take a crack at
debugging.
> 11. Is it possible to search for mail that has no labels without
> saying "!label:label1 AND !label:label2 AND ..."?
>
> I looked a little in the Ferret documentation, but didn't find a way.
> I was trying to do this to get at some mail I archived accidentally
> before applying labels.
Interesting question. I don't know of a better way. If there were one it
would be in the Ferret documentation. I suppose you could use DeMorgan's
law to save yourself a few characters though. :)
--
William <wmorgan-sup at masanjin.net>
next prev parent reply other threads:[~2008-01-10 6:34 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 [this message]
2008-03-26 5:57 ` Guarded Identity
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=1199944172-sup-660@south \
--to=wmorgan-sup@masanjin.net \
/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