From: iny+dev@iki.fi (Ilpo Nyyssönen)
Subject: [sup-talk] Handling big mailing lists
Date: Wed, 29 Jul 2009 20:24:43 +0300 [thread overview]
Message-ID: <m3prbjwgf8.fsf@iny.iki.fi> (raw)
In-Reply-To: <1248874122-sup-3830@masanjin.net>
William Morgan <wmorgan-sup at masanjin.net> writes:
> Sup currently only orders chronologically. It would not be difficult to
> add a second level of user-defined sorting *on top* of the chronological
> one, but it would be difficult, if not impossible, to order all email in
> the index by an arbitrary function.
I'm not talking about ordering of emails, I'm talking about ordering of
the labels.
When I start my daily routine, I want to see a list of labels with
numbers telling how many unread emails each has. Labels containing
nothing new must be hidden. And this list must be sorted to priority
order. Then I want to read those labels through in that order.
How many labels would I have? At least tens, probably over hundred.
>> And can I continue reading the next label in that order after I have
>> finished the one before?
>
> Certainly, but not automatically. You can view one label, and then pick
> another label to view, etc.
Picking one from alphabetically sorted list or writing it is not usable.
I don't remember the order, I just want to get the next one.
>> Then about the expiration. The linux-kernel mailing list gets so much
>> email that some kind of expiration is a must.
>
> You don't want to just buy a bigger hard drive?
It's not a disk space problem. The problem is that many things would get
slow (or I would need to configure exceptions) and I just do not have
any need for them. They are all in searchable mailing list archives
anyway.
And another point is that I actually prefer not to order mailing lists.
It is much easier to just get them with nntp from news.gmane.org. How? I
have a nntp to imap gateway and I use it to read also from other nntp
servers. The thing here is that nntp servers usually do expire messages
and so to be able to use that with Sup, it would need to tolerate the
expiration.
> That's best left to another process. You'll then have to tell Sup which
> messages were deleted so that it can remove them from the index.
So, I don't do the expiration. I guess it should be possible to find out
the ones that went away when checking for new ones.
> Let me know when you're at this point and I can help you---it will
> require a brief Ruby script.
Well, it is looking like in current state I won't even start trying.
>> I would actually recommend reading linux-kernel to test Sup. :)
>
> I read ruby-talk, which is probably not too far off.
Hmm,
http://dir.gmane.org/gmane.comp.lang.ruby.general
http://dir.gmane.org/gmane.linux.kernel
I guess so. How long it takes to index few months of ruby-talk?
Could Sup use IMAP search features?
--
Ilpo Nyyss?nen # biny # /* :-) */
next prev parent reply other threads:[~2009-07-29 17:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-29 6:09 Ilpo Nyyssönen
2009-07-29 12:54 ` Marc Weber
2009-07-29 13:46 ` William Morgan
2009-07-29 17:24 ` Ilpo Nyyssönen [this message]
2009-08-03 17:31 ` 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=m3prbjwgf8.fsf@iny.iki.fi \
--to=iny+dev@iki.fi \
/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