[Orgmode] Re: Behavior of Gnus when called from an hyperlink

[Sébastien Vauban]

Hi David,

David Maus wrote:
> Sébastien Vauban wrote:
>> What would be your pieces of advice in such a case? Do I need to test
>> something extra? Get a local imap server? Others (like asking for fixing
>> the search on our Courier mail server)?
>
> Well, IMO there might be nothing to "fix" on the server side. Although a
> user might expect searches to be fast there is no directive in the specs
> about the fastness of the SEARCH command. This should of course not prevent
> you from dropping a mail to the IMAP server admins about your problem to at
> least point at this performance issue with large mailboxes.
>
> At the client side I asked myself why Gnus does not use the cached message.
> Some vague guesses:
>
>> I've checked the cache; in /home/sva/Mail/cache/nnimap+me:INBOX.work, I have 
>> a
>> copy of the linked email:
>
>>   -rw-r--r-- 1 sva sva   1631 2010-06-28 14:09 28606
>
> Okay, Gnus caches the message but would have to search in all cached
> messages for the message id header. "28606" might be the UID of the message
> in the mailbox. To confirm this login manually and prefix the search command
> with "UID"
>
> ,----
> | 0x3 UID SEARCH HEADER "Message-ID" "address@hidden"
> `----
>
> If this search returns 28606 then we can assume that Gnus indeed caches by
> UID[1]. This means that Gnus needs to query the server what the UID of the
> message with a particular message id is and could than use the cache.

Your guess is right:

--8<---------------cut here---------------start------------->8---
address@hidden />nc -vv mail imap
Connection to mail 143 port [tcp/imap2] succeeded!
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT 
THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS XMAGICTRASH] 
Courier-IMAP ready. Copyright 1998-2004 Double Precision, Inc.  See COPYING for 
distribution information.
0x1 LOGIN "sva" "<not-displayed>"
0x1 OK LOGIN Ok.
0x2 SELECT INBOX.mc
* FLAGS ($MDNSent Junk gnus-save gnus-forward NonJunk $Forwarded \Draft 
\Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS ($MDNSent Junk gnus-save gnus-forward NonJunk $Forwarded 
\* \Draft \Answered \Flagged \Deleted \Seen)] Limited
* 27084 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1097250695] Ok
* OK [MYRIGHTS "acdilrsw"] ACL
0x2 OK [READ-WRITE] Ok
0x3 UID SEARCH HEADER "Message-ID" "address@hidden"

* SEARCH 28606
0x3 OK SEARCH done.
--8<---------------cut here---------------end--------------->8---


> This is the point where I conclude that there can't be done anything about
> it except modifying Gnus' cache mechanism.[2]

Do you think that would happen?  Are there people aware of this, and willing
to do such a change?

Problem is I focused on Gnus for 5 years, after a careful election of the
program I would invest time in -- by reading a lot of blogs and comments on
the Web. I think I'm too bound to it now, to give a try to WL. Or you should
really insist a lot ;-)


> So the fall back would be: Not to keep everything in the IMAP mailbox but
> expire old messages to a local folder. Here I have rule that says:
> Everything older than 180 days is moved from IMAP inbox to a local archive
> folder. The implications are, of course, that links to messages older than
> 180 days break. To mitigate this I use Namazu[3] to index my local archives
> and in case I need to follow such a broken Org link I could open the link by
> performing a search for the message-id first[4].

It seems WL is better suited for this. Your solution with 180 days is a nice
work around, but I fear its impacts -- having broken links.


> In the case of Gnus we might modify org-gnus-open to, say, perform a mairix
> search for the message id if called with prefix and open the message in the
> search result folder.

Would I have to invest time on looking at mairix possibilities?

Will/Would someone work on your proposed workaround?

Thanks a lot for your help (addressed to you, and Nick, Tassilo, Bernt, in
particular for this topic),
  Seb

-- 
Sébastien Vauban