Question about mail archive

Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1237 bytes --]

Hi guys,

it is well possible that something like this has been discussed before
and the answer is in the archives (I couldn't find it, though). I'm
currently very busy organizing the FSF Europe and hence low on time -
also I'm currently not subscribed to this list, so if you reply,
please include my email address. Thanks and apologies in advance...

I have a set of files named in the standard YYYY-MM denomination in a
single directory, each of which contains several mails simply piped
successively into them. They do not have the gnus pseudo-headers,
though - and they shouldn't have them. Access should be strictly
read-only.

As you might have guessed, I want to access them as additional mail
archives in gnus and I'm having problems getting gnus to
cooperate. The files DO contain mails, but gnus always claims there
are no articles.

Tried several backends with different settings: no success.

Can someone give me a quick hint where to look?

Regards,
                Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: Question about mail archive

[Kai Großjohann]

On 07 Apr 2001, Georg C. F. Greve wrote:

> I have a set of files named in the standard YYYY-MM denomination in
> a single directory, each of which contains several mails simply
> piped successively into them. They do not have the gnus
> pseudo-headers, though - and they shouldn't have them. Access should
> be strictly read-only.

You should be able to read a single file by using `G f', then entering
the name of the file.

Or do you want a single group for all of the files in the directory?

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1183 bytes --]

Hi Kai,

 || On 07 Apr 2001 16:54:11 +0200
 || Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote: 

 >> I have a set of files named in the standard YYYY-MM denomination
 >> in a single directory, each of which contains several mails simply
 >> piped successively into them. They do not have the gnus
 >> pseudo-headers, though - and they shouldn't have them. Access
 >> should be strictly read-only.

 kg> You should be able to read a single file by using `G f', then
 kg> entering the name of the file.

Yes, this works and solves my immediate problems... thanks a lot!

 kg> Or do you want a single group for all of the files in the
 kg> directory?

That will probably become too problematic because it'll get too big
(and hence slow), I fear.

I feel that the mail-archiving could be more elegant somehow, but I
cannot put my finger on it or tell you how I would change it. Oh
well... 

Regards,
                Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: Question about mail archive

[Kai Großjohann]

On 07 Apr 2001, Georg C. F. Greve wrote:

> I feel that the mail-archiving could be more elegant somehow, but I
> cannot put my finger on it or tell you how I would change it. Oh
> well... 

I just leave old messages in the normal mail groups.  (I use nnml.)
Then Gnus just reads the .overview file when you enter a group, but
otherwise the many messages are not a problem.

When a group contains 3,000 old messages, say, I move the old messages
to a *.A group (`A' for archive).  Also nnml.  Works well for me.  But
the volume is rarely so high that I have to do it more often than
every half year or so.

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 3329 bytes --]

 || On 07 Apr 2001 17:30:56 +0200
 || Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote: 

 >> I feel that the mail-archiving could be more elegant somehow, but
 >> I cannot put my finger on it or tell you how I would change it. Oh
 >> well...

 kg> I just leave old messages in the normal mail groups.  (I use
 kg> nnml.)  Then Gnus just reads the .overview file when you enter a
 kg> group, but otherwise the many messages are not a problem.

Hm. Maybe I should start using nnml, but them I'll need to make sure
I'm not losing mail in the process.

 kg> When a group contains 3,000 old messages, say, I move the old
 kg> messages to a *.A group (`A' for archive).  Also nnml.  

So you have your archives in nnml, too? 

 kg> Works well for me.  But the volume is rarely so high that I have
 kg> to do it more often than every half year or so.

Hm... I don't have a big problem with archives in one file per
month, it works reasonably well and is fast enough for when you need
to access the archives, it seems. 

Although I should really investigate how to make the summary show the
Recipient instead of the Sender for the archives of mails I sent... 

My preferred way to use it would normally be to have the incoming
groups as nnml, delete spam and things that are not important in the
long run, keep things I need to deal with in the groups until it's
done and move the interesting things/things I replied to to an archive
group.

It should be possible to access the archive in a way that I ONLY get
mail I wrote or mail I received, but also that I can have them
displayed threaded. I fear this is a little too complex/complicated
for any single program, though... :-)


But I have a few questions about the nnml Backend:
 It is better suited for NFS, right?
 How are the message file-names determined? Simply incremental?


I'm asking this because it might provide a solution for the main
problem I'm always facing that isn't solved satisfactory yet. I have
two machines I usually read/write my mail on, my machine at home and
my laptop. Both machines should be able to become the "primary" mail
host when being disconnected and receive mail even if the other
machine is down for a while. If they synchronize, they should
synchronize their archives and their normal mail groups with all flags
so I know on both machines which mail I already replied to and which
has been dealt with.

Currently I'm using the rather crude solution that mail is
automatically delivered to BOTH machines (to the laptop via UUCP), I
"unison" the ~/News tree where I save things and put the whole
~/Mail/mail directory structure of each machine into a
~/Mail/<othermachinename> tree on the other machine. My .gnus file
adds the tree of the other machine based on the name of the machine
gnus is running on. 

This is ugly but makes sure nothing gets lost. Everything is kept
doubly... but flags are lost.

If you can think of a better way, let me know, I'd be really glad to
hear about it.

Regards & thanks,
                        Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: Question about mail archive

[Alex Schroeder]

"Georg C. F. Greve" <greve@gnu.org> writes:

> Although I should really investigate how to make the summary show the
> Recipient instead of the Sender for the archives of mails I sent... 

I set gnus-ignored-from-addresses in order to do that (and
message-dont-reply-to-names, because it's the same regexp).

(setq gnus-ignored-from-addresses 
      (concat "\\(Alex Schroeder <\\)?\\("
	      (regexp-opt
	       '("a.schroeder@xxx.ch"
		 "a.schroeder@xxx.com"
		 "asc@xxx.com"
		 "asc@xxx.ch"
		 "alex@gnu.org"
		 "pbem@xxx.ac.at"
		 "kensanata@yahoo.com"
		 "kensanata@xxx.ch"))
	      "\\)>?")
      message-dont-reply-to-names gnus-ignored-from-addresses)

> It should be possible to access the archive in a way that I ONLY get
> mail I wrote or mail I received, but also that I can have them
> displayed threaded. I fear this is a little too complex/complicated
> for any single program, though... :-)

Hey, this is Gnus, remember?  You should be able to use Gcc: headers
for outgoing mails (different per group you are in, depending on
gnus-posting-styles.  That will put the outgoing mails in different
folders.  Split the incoming mails into other folders, using
nnmail-split-methods (I use nnml as well).  Then create virtual groups
-- for each pair of incoming and outgoing messages of a certain type.
Now you have three groups for each type of message:  All, only
incoming or only outgoing.  All of them threaded, of course.

> But I have a few questions about the nnml Backend:
>  It is better suited for NFS, right?

Huh?  Why?  No, it's just one file per message, so maybe you waste a
lot of space on your harddisk (if messages are significantly smaller
than inodes/sectors/whatever -- but usually I just don't care).

>  How are the message file-names determined? Simply incremental?

Numbers, incremented automatically.

> If they synchronize, they should
> synchronize their archives and their normal mail groups with all flags
> so I know on both machines which mail I already replied to and which
> has been dealt with.

Hm, that would be harded...  Somebody else?  :)

Alex.
-- 
http://www.geocities.com/kensanata/emacs.html
"No images on Emacsen <v21; use XEmacs or wait for v21."

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 3627 bytes --]

Hi Alex,

 || On 07 Apr 2001 19:34:57 +0200
 || Alex Schroeder <alex@gnu.org> wrote: 

 >> Although I should really investigate how to make the summary show
 >> the Recipient instead of the Sender for the archives of mails I
 >> sent...

 as> I set gnus-ignored-from-addresses in order to do that (and
 as> message-dont-reply-to-names, because it's the same regexp).

But this is for all groups, right?

 >> It should be possible to access the archive in a way that I ONLY
 >> get mail I wrote or mail I received, but also that I can have them
 >> displayed threaded. I fear this is a little too
 >> complex/complicated for any single program, though... :-)

 as> Hey, this is Gnus, remember?  

Oh yeah... THAT's what I'm using. Thanks for pointing it out... *g*

 as> You should be able to use Gcc: headers for outgoing mails

Have been doing this for years now... works fine and nnspool is fine
for the archives, as far as I'm concerned.

 as> (different per group you are in, depending on
 as> gnus-posting-styles.  That will put the outgoing mails in
 as> different folders.  

I could do this but I don't see the need to do it... 

 as> Split the incoming mails into other folders, using
 as> nnmail-split-methods (I use nnml as well).  

Yeah, I've been using mail-splitting for a long time now, too. 

Since you guys seemed to favor nnml, I just moved my setup to it and I
must say I like it - it is much faster... good stuff.

 as> Then create virtual groups -- for each pair of incoming and
 as> outgoing messages of a certain type.  Now you have three groups
 as> for each type of message: All, only incoming or only outgoing.
 as> All of them threaded, of course.

Yeah, but this is not quite what I want. I thought about having it in
a way that I have

 - the incoming groups (split depending on all kinds of criteria)
 - a sent mail archive group sorted per month (as usual)

(this is what I have now) and 

 - ONE archive group per month for processed incoming mail

(this is what I don't know how to do properly at the moment)

 >> But I have a few questions about the nnml Backend: It is better
 >> suited for NFS, right?

 as> Huh?  Why?  

I think I read this somewhere. It makes some sense, though, smaller
files look like a better idea to me.

 as> No, it's just one file per message, so maybe you waste a lot of
 as> space on your harddisk (if messages are significantly smaller
 as> than inodes/sectors/whatever -- but usually I just don't care).

It is MY harddisk and MY machine, so I feel completely free to waste
as much space as I want. :-)

 >> How are the message file-names determined? Simply incremental?

 as> Numbers, incremented automatically.

Hm. If this were, say, message-id based, it would make synchronization
much easier.

 >> If they synchronize, they should synchronize their archives and
 >> their normal mail groups with all flags so I know on both machines
 >> which mail I already replied to and which has been dealt with.

 as> Hm, that would be harded...  

I know. This is the big still-to-be-solved problem of all MUAs. 

But nnml seems to be closer to a solution already. If just the active
and .newsrc.eld files weren't so sensitive... a smart way to
synchronize them would probably be the crucial problem to be solved.

Regards,
                Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: Question about mail archive

[Kai Großjohann]

On 08 Apr 2001, Georg C. F. Greve wrote:

>  as> I set gnus-ignored-from-addresses in order to do that (and
>  as> message-dont-reply-to-names, because it's the same regexp).
> 
> But this is for all groups, right?

I just show messages from me as "-> recipient" in the summary, and I'm
happy with that.  I do this via setting gnus-ignored-from-addresses
and

    (setq nnmail-extra-headers '(To Cc))
    (setq gnus-extra-headers nnmail-extra-headers)

And, finally, I use the %f spec in gnus-summary-line-format rather
than the %n spec.

I find that it's okay to always see "-> recipient" in all groups for
messages authored by me, no need to restrict it to some groups.

>  as> Then create virtual groups -- for each pair of incoming and
>  as> outgoing messages of a certain type.  Now you have three groups
>  as> for each type of message: All, only incoming or only outgoing.
>  as> All of them threaded, of course.
> 
> Yeah, but this is not quite what I want. I thought about having it
> in a way that I have
> 
>  - the incoming groups (split depending on all kinds of criteria)
>  - a sent mail archive group sorted per month (as usual)
> 
> (this is what I have now) and 
> 
>  - ONE archive group per month for processed incoming mail
> 
> (this is what I don't know how to do properly at the moment)

Hm.  When a message comes in and you have processed it, do you want to
move or to copy it to the archive group?  Anyway, maybe a simple
keybinding that you can use rather than `d' would be sufficient?  A
command which marks the article as read and then does
gnus-summary-move-article to the right group?

>  >> But I have a few questions about the nnml Backend: It is better
>  >> suited for NFS, right?
> 
>  as> Huh?  Why?  
> 
> I think I read this somewhere. It makes some sense, though, smaller
> files look like a better idea to me.

Hm.  Any performance advantage that nnml might have will also be true
for the local disk.  And using nnml, you really shouldn't allow any
program other than Gnus to write to ~/Mail.  (In fact, nnmh is the
only backend which _might_ be different in this regard, but nnmh is
very slow.)

Maybe nnmaildir is a good backend for NFS, since that doesn't require
file locking.  Hm.  Any nnmaildir experts who can help?

>  >> If they synchronize, they should synchronize their archives and
>  >> their normal mail groups with all flags so I know on both
>  >> machines which mail I already replied to and which has been
>  >> dealt with.
> 
>  as> Hm, that would be harded...  
> 
> I know. This is the big still-to-be-solved problem of all MUAs. 
> 
> But nnml seems to be closer to a solution already. If just the
> active and .newsrc.eld files weren't so sensitive... a smart way to
> synchronize them would probably be the crucial problem to be solved.

For synchronizing email across several machines, I used to sync
~/Mail, ~/News, ~/.newsrc* and ~/.nnmail-cache.  It was important to
take care about the direction, that's all.  Using rsync, this was
reasonably fast.  (I had 200 or 300 MB of mail back then, and a no-op
sync (when both directories were equal) took less than two minutes
over a 64k ISDN line.)

But this method works equally well for all backends.  Just rsync the
right files and directories.

Another approach to syncing mail on different machines is to use an
IMAP server and maybe the Agent (unplugged) facility offered by Gnus.

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Alex Schroeder]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> For synchronizing email across several machines, I used to sync
> ~/Mail, ~/News, ~/.newsrc* and ~/.nnmail-cache.  It was important to
> take care about the direction, that's all.  Using rsync, this was
> reasonably fast.  (I had 200 or 300 MB of mail back then, and a no-op
> sync (when both directories were equal) took less than two minutes
> over a 64k ISDN line.)

Hm, I didn't ask this, so maybe it is irrelevant -- but how did you
sync this exactly?  Assume you have an nnml directory ~/Mail/emacs on
two machines, both machines get mail.  Doesn't that mean that for each
filename a mail exists on either machine -- and there is no guaranty
that the file contains the same mail?  Then sync would by impossible,
right?

Alex.
-- 
http://www.geocities.com/kensanata/emacs.html
"Emacs 21 will be out when it comes out.  No beta available."

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 2962 bytes --]

Hi Kai,

 || On 08 Apr 2001 20:36:36 +0200
 || Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote: 

 >> But this is for all groups, right?

 kg> I just show messages from me as "-> recipient" in the summary,
 kg> and I'm happy with that.  I do this via setting
 kg> gnus-ignored-from-addresses and

 kg>     (setq nnmail-extra-headers '(To Cc))
 kg>     (setq gnus-extra-headers nnmail-extra-headers)

 kg> And, finally, I use the %f spec in gnus-summary-line-format
 kg> rather than the %n spec.

 kg> I find that it's okay to always see "-> recipient" in all groups
 kg> for messages authored by me, no need to restrict it to some
 kg> groups.

Yeah, this looks pretty good. It seems like it only works for nndoc
groups and not nnfolder ones, though. Weird.

 >> - ONE archive group per month for processed incoming mail
 >> (this is what I don't know how to do properly at the moment)

 kg> Hm.  When a message comes in and you have processed it, do you
 kg> want to move or to copy it to the archive group?  Anyway, maybe a
 kg> simple keybinding that you can use rather than `d' would be
 kg> sufficient?  A command which marks the article as read and then
 kg> does gnus-summary-move-article to the right group?

Yeah, this would probably sufficient if it prompted me with a
reasonable name by default... maybe passing something like

 (setq gnus-processed-message-archive-group
      '(concat "recv." (format-time-string 
			"%Y-%m" (current-time))))

as the default name for the group to move to? 

<try>

Hm. EMACS doesn't seem to like this when I pass it to
gnus-summary-move-article...

 kg> Hm.  Any performance advantage that nnml might have will also be
 kg> true for the local disk.  

Of course - but NFS is significantly slower than local disk
access... that's why I think it makes even more of a difference
there. 

 kg> Maybe nnmaildir is a good backend for NFS, since that doesn't
 kg> require file locking.  Hm.  Any nnmaildir experts who can help?

But I still guess that'd be slower than nnml...

 >> But nnml seems to be closer to a solution already. If just the
 >> active and .newsrc.eld files weren't so sensitive... a smart way
 >> to synchronize them would probably be the crucial problem to be
 >> solved.

 kg> For synchronizing email across several machines, I used to sync
 kg> ~/Mail, ~/News, ~/.newsrc* and ~/.nnmail-cache.  It was important
 kg> to take care about the direction, that's all.  

Yeah - that's probably the only way. Still I'd like something that is
more stable and doesn't have the danger of syncing in the wrong
direction. 

I'll think some more about this, I guess.

Regards,
                Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: Question about mail archive

[Kai Großjohann]

On 08 Apr 2001, Georg C. F. Greve wrote:

>  || On 08 Apr 2001 20:36:36 +0200
>  || Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote: 
> 
>  kg> Hm.  When a message comes in and you have processed it, do you
>  kg> want to move or to copy it to the archive group?  Anyway, maybe
>  kg> a simple keybinding that you can use rather than `d' would be
>  kg> sufficient?  A command which marks the article as read and then
>  kg> does gnus-summary-move-article to the right group?
> 
> Yeah, this would probably sufficient if it prompted me with a
> reasonable name by default... maybe passing something like
> 
>  (setq gnus-processed-message-archive-group
>       '(concat "recv." (format-time-string 
> 			"%Y-%m" (current-time))))
> 
> as the default name for the group to move to? 

(gnus-summary-move-article 1 (format-time-string "recv.%Y-%m"))

Try to eval this expression using M-: on a msg.  Does it move the msg
to the right group?

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 790 bytes --]

 || On 08 Apr 2001 22:23:44 +0200
 || Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote: 

 kg> (gnus-summary-move-article 1 (format-time-string "recv.%Y-%m"))

 kg> Try to eval this expression using M-: on a msg.  Does it move the
 kg> msg to the right group?

I'm getting the error "nntp does not support article copying" (tried
it on an article in a nnml: mail group).

Regards,        
                Georg


P.S. Found what the problem with the summary was... forgot to have it
regenerate the ".nov" files. I guess I'm gettin tired.

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: Question about mail archive

[Kai Großjohann]

On 08 Apr 2001, Georg C. F. Greve wrote:

>  kg> (gnus-summary-move-article 1 (format-time-string "recv.%Y-%m"))
> 
> I'm getting the error "nntp does not support article copying" (tried
> it on an article in a nnml: mail group).

I'm also tired.  It should be "nnml:recv.%Y-%m"...

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1633 bytes --]

Hi Alex,

 || On 08 Apr 2001 21:19:39 +0200
 || Alex Schroeder <alex@gnu.org> wrote: 

 >> For synchronizing email across several machines, I used to sync
 >> ...
 >> minutes over a 64k ISDN line.)

 as> Hm, I didn't ask this, so maybe it is irrelevant -- but how did
 as> you sync this exactly?  Assume you have an nnml directory
 as> ~/Mail/emacs on two machines, both machines get mail.  Doesn't
 as> that mean that for each filename a mail exists on either machine
 as> -- and there is no guaranty that the file contains the same mail?
 as> Then sync would by impossible, right?

Not quite. You'd get a lot of duplicate messages, but that shouldn't
hurt. The limiting factor is that with this setup, gnus MUST never run
on more than ONE of the machines.

This seems to be a standard problem - if gnus had a pre-startup check
for a lockfile (let's say a file called "lock" in the Mail directory),
this could easily be solved.

What about this behaviour:

 Only if the machine name in the lockfile matches the local host, gnus
 starts up. 

 If no lockfile is present, it creates it and writes the local
 hostname into it.

 The lockfile is among the synced files. 

Then the lockfile could also be used to determine the direction of the
file-sync. After the sync, the lockfile is deleted.

That should be a little safer, at least.

Regards,
                Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 696 bytes --]

 || On 08 Apr 2001 22:41:38 +0200
 || Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote: 

 kg> On 08 Apr 2001, Georg C. F. Greve wrote:
 kg> (gnus-summary-move-article 1 (format-time-string "recv.%Y-%m"))
 >> 
 >> I'm getting the error "nntp does not support article copying" (tried
 >> it on an article in a nnml: mail group).

 kg> I'm also tired.  It should be "nnml:recv.%Y-%m"...

Well. I'm more awake now. Put the following function into my .gnus and
bound it to "C-A" - now "E" expires, and "CTRL-A" archives. This seems
nice enough. Thanks for your help.

Oh. And I set the first argument to "nil" so you can tag several
messages and archive them all at once.


[-- Attachment #1.2: Type: application/emacs-lisp, Size: 212 bytes --]

[-- Attachment #1.3: Type: text/plain, Size: 261 bytes --]


Regards,
                Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: Question about mail archive

[Kai Großjohann]

On 08 Apr 2001, Alex Schroeder wrote:

> Hm, I didn't ask this, so maybe it is irrelevant -- but how did you
> sync this exactly?  Assume you have an nnml directory ~/Mail/emacs
> on two machines, both machines get mail.

In my scenario, only one machine gets mail.  Does that answer your
question?

The syncing was done via rsync:

rsync -avz --delete grossjoh@work:Mail/ ~/Mail/

... and so on.  And then there was some voodoo to tell Gnus on the
@work machine to fetch mail and to send it.

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Dan Christensen]

"Georg C. F. Greve" <greve@gnu.org> writes:

>  kg> I just show messages from me as "-> recipient" in the summary,
>  kg> and I'm happy with that.  I do this via setting
>  kg> gnus-ignored-from-addresses and
> 
>  kg>     (setq nnmail-extra-headers '(To Cc))
>  kg>     (setq gnus-extra-headers nnmail-extra-headers)
> 
>  kg> And, finally, I use the %f spec in gnus-summary-line-format
>  kg> rather than the %n spec.
> 
> Yeah, this looks pretty good. It seems like it only works for nndoc
> groups and not nnfolder ones, though. Weird.

I think you have to run nnfolder-generate-active-file.

-- 
Dan Christensen
jdc+news@uwo.ca

Re: Question about mail archive

[Paul Jarc]

"Georg C. F. Greve" <greve@gnu.org> writes:
>  || On 08 Apr 2001 20:36:36 +0200
>  || Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote: 
>  kg> Maybe nnmaildir is a good backend for NFS, since that doesn't
>  kg> require file locking.  Hm.  Any nnmaildir experts who can help?
> 
> But I still guess that'd be slower than nnml...

I haven't measured, but I don't see why it would be.  nnmaildir uses
one file per message and (currently) one file per group for NOV data.
The new version uses one file per message for NOV data (hooray for
ReiserFS), and automatically regenerates the NOV data when the message
file is newer than the NOV file.  A limited (configurable) number of
articles have their NOV data cached in memory while the server is
open.

Marks are very easy to manage.  Suppose a message is stored in
"mailbox/cur/foo:info".  It has the "tick" mark if and only if the
file "mailbox/.nnmaildir/mark-tick/foo" exists.  (The mark-
directories will actually be populated with hard links to a single
file when marks are written, but if you create a file manually, that's
ok too; it'll be recognized as a mark.)  Since marks are stored on
disk, articles are renumbered each time the server is opened, so you
don't have gaps, and Gnus's estimate of the number of articles tends
to be closer to being right.

The new version is almost done - just a bit more debugging to do.

One thing you don't get with nnmaildir is splitting.  I do all my
splitting during delivery (mostly by using different addresses for
different mailboxes), so I've never needed it, and no one's asked for
it.  But I wonder why splitting uses nnfoo-save-mail instead of
nnfoo-request-accept-article... if not for that, I think nnmaildir
would automatically be usable with splitting.


paul

Re: Question about mail archive

[Kai Großjohann]

On 09 Apr 2001, Paul Jarc wrote:

> But I wonder why splitting uses nnfoo-save-mail instead of
> nnfoo-request-accept-article...

I think it's for efficiency.  What's more efficient about
nnfoo-save-mail than nnfoo-request-accept-article, I don't know.

nnmaildir sounds pretty impressive.  If I wasn't about to migrate to
nnimap, I think I'd consider going to nnmaildir.

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1598 bytes --]

Hi Paul,

 || On 09 Apr 2001 14:39:58 -0400
 || prj@po.cwru.edu (Paul Jarc) wrote: 

 >> But I still guess that'd be slower than nnml...

 pj> I haven't measured, but I don't see why it would be.  nnmaildir
 pj> ...
 pj> (configurable) number of articles have their NOV data cached in
 pj> memory while the server is open.

Hm. Yeah, this seems to have been my fault, I thought nnmaildir used
bigger files.

 pj> Marks are very easy to manage.  Suppose a message is stored in
 pj> ...
 pj> the number of articles tends to be closer to being right.

 pj> The new version is almost done - just a bit more debugging to do.

So how far are you? How stable is it? At least it seems there is no
documentation for it in the CVS version.

 pj> One thing you don't get with nnmaildir is splitting.  

Okay, that rules it out for me, unfortunately. I would have liked to
give it a try, but I depend on mail splitting... no chance for me to
manage my mail traffic otherwise. 


By the way: I just wondered whether there is a way to have the summary
buffer sorted in a way that articles marked as "expirable" normally
don't show up at all or are at least all sorted out to the end of the
summary even when entering a group with no new mail. 

This is something I always wanted to do but never found in the docs.

Regards,
                Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: Question about mail archive

[Paul Jarc]

"Georg C. F. Greve" <greve@gnu.org> writes:
>  || On 09 Apr 2001 14:39:58 -0400
>  || prj@po.cwru.edu (Paul Jarc) wrote: 
>  pj> The new version [of nnmaildir] is almost done - just a bit more
>  pj> debugging to do.
> 
> So how far are you? How stable is it?

I've had no problems using the current version.  The new version is,
at the present moment, unusable, due to a (simple, I think) bug in
group naming.  I hope to get it out this week, but that may be a bit
optimistic.

> At least it seems there is no documentation for it in the CVS
> version.

It isn't part of the Gnus distribution.
<URL:http://multivac.cwru.edu/nnmaildir/>

>  pj> One thing you don't get with nnmaildir is splitting.  
> 
> Okay, that rules it out for me, unfortunately.

I guess I'll put nnmaildir-save-mail on the todo list, then. :)

Then I think you'll be able to use it with splitting by having a
nnmail-derived backend (nnmaildir is *not* nnmail-derived) gather your
mailfrom mail-sources and split it into the destination (nnmaildir, or
not) groups.  The server that does the splitting need not have any
actual groups on it, I think, but I could be wrong.

> By the way: I just wondered whether there is a way to have the summary
> buffer sorted in a way that articles marked as "expirable" normally
> don't show up at all or are at least all sorted out to the end of the
> summary even when entering a group with no new mail. 

Well, you could use a really low expiry-wait and have expired mail get
sent to another group, which has a normal expiry-wait.  Then you have
other problems, though: either you have double the number of groups,
or you no longer can easily tell which group each expired message came
from; also, the messages show up as new after they're expired into the
other group.  (The new nnmaildir helps here, though - you can set the
group parameter always-marks to '(read), and nnmaildir will report
that all articles have the read mark.)


paul

Re: Question about mail archive

[Kai Großjohann]

On 09 Apr 2001, Georg C. F. Greve wrote:

> Okay, that rules it out for me, unfortunately. I would have liked to
> give it a try, but I depend on mail splitting... no chance for me to
> manage my mail traffic otherwise. 

I guess you can do mail splitting outside of Gnus.  Procmail would be
an idea.

However, that way you might miss nnmail-split-fancy-with-parent.  If
you have never used it, you won't miss it, but if you use it now I'm
guessing you will miss it dearly.

Or you could install an MTA which groks maildir format out of the box,
then the MTA could do the splitting.  Or maybe you can even use plus
addressing: a message sent from group foo could have greve+foo@gnu.org
as reply-to address, so all replies to that message will automatically
go to group foo.

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Karl Kleinpaste]

prj@po.cwru.edu (Paul Jarc) writes:
> The new version uses one file per message for NOV data

I have to observe that the whole point of the development of NNTP's
XOVER facility is because news servers were suffering so badly in the
face of user agents entering a group and wanting header data for
hundreds of articles at a time, requiring opening hundreds of article
files in order to find those headers.  System call tracing of NNTP
reader servers revealed that a hefty percentage of their total time
was being wasted by having the server open, read, and immediately
close every single article file in the sequence, just to dig out a few
headers, and that was all just for group entry, not including the
user's actual article reading choices.  Overviews were developed as a
way of saving the most common, important headers in a single flat
file, so that only a single open/read/close was needed, and some quite
spiffy code was developed to make searching that flat file for a
specified article range very easy and efficient.

If you have resorted to per-message overviews, you have in effect
utterly destroyed the very purpose for which overviews were created.

Re: Question about mail archive

[Dan Christensen]

"Georg C. F. Greve" <greve@gnu.org> writes:

> By the way: I just wondered whether there is a way to have the summary
> buffer sorted in a way that articles marked as "expirable" normally
> don't show up at all or are at least all sorted out to the end of the
> summary even when entering a group with no new mail. 
> 
> This is something I always wanted to do but never found in the docs.

In the message I posted a week ago, I showed how I do this.
However, it has the problem that it generates the summary buffer
twice, so it is a little slow.  I've included the message below.

Dan

From: Dan Christensen <jdc+news@uwo.ca>
Subject: not showing expirable articles
To: ding@gnus.org
Date: 02 Apr 2001 17:47:07 -0400
Message-ID: <87puevotyc.fsf@uwo.ca>

This was discussed a long time ago, but I don't know if a good
solution was ever proposed.  I use auto-expire, or manually mark
articles as expirable.  When I've done this, I would like it if
by default such articles didn't show up in the summary buffer
(unless I enter with `C-u RET' or something like that).  And
that the expirable articles could be brought in with a keystroke
like `/ E'.

I accomplish this with the following code:

; This runs only when the summary is first prepared, and not after
; other limiting commands.  Thus `/ w' pop's this limit, and others,
; as one would like it to.
(add-hook 'gnus-summary-prepared-hook 
          (lambda ()
            (if (or (string-match "^nnfolder:" gnus-newsgroup-name)
                    (string-match "^nnvirtual:Both" gnus-newsgroup-name)
                    (string-match "^nnml:" gnus-newsgroup-name))
                (jdc-gnus-summary-limit-exclude-unwanted))))

(defun jdc-gnus-summary-limit-exclude-unwanted ()
  (interactive)
  (gnus-summary-limit-to-marks "EG" t))

I also add the following to my summary-mode-hook:

(define-key gnus-summary-mode-map "/e" 'jdc-gnus-summary-limit-exclude-unwanted)

Then `/ w' shows me the expired articles when I choose to see them,
and `/ e' gets rid of them.

The only problem with this set-up is that entering a group is quite
slow, since the summary buffer gets generated twice, and the first
time tends to be a fair bit larger than the second time.  So it is
usually more than a factor of two slower than necessary.

What I would like is a variable "gnus-summary-show-expirable".  If
this is nil, then expirable articles aren't included by default,
but can be brought in with a new command.  I would suspect that
many users would like this behaviour.

Any thoughts?

-- 
Dan Christensen
jdc+news@uwo.ca

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 2700 bytes --]

Paul,

 || On 09 Apr 2001 16:36:00 -0400
 || prj@po.cwru.edu (Paul Jarc) wrote: 

 pj> The new version [of nnmaildir] is almost done - just a bit more
 pj> debugging to do.

 >> So how far are you? How stable is it?

 pj> I've had no problems using the current version.  The new version
 pj> is, at the present moment, unusable, due to a (simple, I think)
 pj> bug in group naming.  I hope to get it out this week, but that
 pj> may be a bit optimistic.

:-)

 >> At least it seems there is no documentation for it in the CVS
 >> version.

 pj> It isn't part of the Gnus distribution.
 pj> <URL:http://multivac.cwru.edu/nnmaildir/>

Okay, that explains it. Any chance it'll be put into the main
distribution at some point? 

 pj> One thing you don't get with nnmaildir is splitting.  

 >> Okay, that rules it out for me, unfortunately.

 pj> I guess I'll put nnmaildir-save-mail on the todo list, then. :)

:-)))))

I know from a very 

 >> By the way: I just wondered whether there is a way to have the
 >> summary buffer sorted in a way that articles marked as "expirable"
 >> normally don't show up at all or are at least all sorted out to
 >> the end of the summary even when entering a group with no new
 >> mail.

 pj> Well, you could use a really low expiry-wait and have expired
 pj> mail get sent to another group, which has a normal expiry-wait.

Yeah, I have thought about somthing similar but thought that there was
maybe another (better) solution.

Now I have an "expired" group with a waiting period of 14 days and
everything else set to 'immediate (or 'never for a few special
cases). That keeps my mail groups nice and clean and has no speed
problems. 

 pj> Then you have other problems, though: either you have double the
 pj> number of groups, or you no longer can easily tell which group
 pj> each expired message came from; 

Not too much of a big deal. If you KNOW you didn't want that article
expired you normally know which one it was. .-) Also there is the good
old "respool" just in case. *g*

 pj> also, the messages show up as new after they're expired into the
 pj> other group.  

I'm simply not subscribed to the expired group (lvl 6). That way I can
get to it with "A A" if I'm looking for something but normally it's
simply invisible.

I'm pretty satisfied with this solution. Not perfect but good enough
to do the job right, I think.

Regards,
                Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1057 bytes --]

Kai,

 || On 09 Apr 2001 22:50:00 +0200
 || Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote: 

 >> Okay, that rules it out for me, unfortunately. I would have liked
 >> to give it a try, but I depend on mail splitting... no chance for
 >> me to manage my mail traffic otherwise.

 kg> I guess you can do mail splitting outside of Gnus.  Procmail
 kg> would be an idea.

 kg> However, that way you might miss nnmail-split-fancy-with-parent.
 kg> If you have never used it, you won't miss it, but if you use it
 kg> now I'm guessing you will miss it dearly.

I have been using it and I would miss it dearly. I'm VERY sure of
that. :-) 

Also I like the way you can do the splitting with the split-fancy
routines and I prefer to have it all in ONE configuration file.

Regards,
                Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1538 bytes --]

Hi Dan,

 || On 09 Apr 2001 21:18:22 -0400
 || Dan Christensen <jdc+news@uwo.ca> wrote: 

 dc> In the message I posted a week ago, I showed how I do this.

Sorry, didn't see that since I'mnot subscribed to the group. I get too
much mail as it is and really couldn't read all of it. Just meant to
ask a simple little question and now I'm deep into posting here, it
seems.

Don't worry, this'll be over soon, though. :)

 dc> However, it has the problem that it generates the summary buffer
 dc> twice, so it is a little slow.  I've included the message below.

Thanks. This is pretty interesting although the "slow" part had me
feeling to badly about it that I chose the other way. :)

 dc> What I would like is a variable "gnus-summary-show-expirable".
 dc> If this is nil, then expirable articles aren't included by
 dc> default, but can be brought in with a new command.  I would
 dc> suspect that many users would like this behaviour.

I agree.

 dc> Any thoughts?

Well. Maybe another idea would be to make the status of the expiry
flag a factor for the summary-sorting function. Then you could sort
them all out on top, at the end, into the threads on top, into the
threads at the end - whatever you like. Sounds very gnus-ish to
me. :-)

Regards,
                Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

nnmail-split-fancy-with-parent (Was: Question about mail archive)

[Mats Löfdahl]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> However, that way you might miss nnmail-split-fancy-with-parent. If
> you have never used it, you won't miss it, but if you use it now I'm
> guessing you will miss it dearly.

That comment made me go ahead and try it. It really seems very useful
and I'd been wanting to for some time but never got around to it.

One thing I noticed is that it does not seem aware of renaming of
groups. For some silly reasons I don't want to go into, after
including nnmail-split-fancy-with-parent in nnmail-split-fancy, I
moved a bunch of messages to an already existing nnfolder group,
renamed the group and then replied to one of the recently moved
articles (with myself as recipient). Where did the message go? It
created a new nnfolder group with the old name of the group I'd just
renamed...


-- 
 Mats Löfdahl

Re: Question about mail archive

[Kai Großjohann]

On 10 Apr 2001, Georg C. F. Greve wrote:

>  || On 09 Apr 2001 22:50:00 +0200
>  || Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote: 
> 
>  kg> However, that way you might miss
>  kg> nnmail-split-fancy-with-parent.  If you have never used it, you
>  kg> won't miss it, but if you use it now I'm guessing you will miss
>  kg> it dearly.
> 
> I have been using it and I would miss it dearly. I'm VERY sure of
> that. :-) 

He he.  Well, I think that the plus addressing trick will be almost as
good.

kai
-- 
Be indiscrete.  Do it continuously.

Re: nnmail-split-fancy-with-parent (Was: Question about mail archive)

[Kai Großjohann]

On 10 Apr 2001, Mats Löfdahl wrote:

> One thing I noticed is that it does not seem aware of renaming of
> groups.

Working around this is simple: a string replace in ~/.nnmail-cache
(then restarting Gnus) will do.  It's not clear to me, however, what a
real solution should look like.  Thoughts?

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 997 bytes --]

 || On 10 Apr 2001 11:42:57 +0200
 || Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote: 

 kg> However, that way you might miss nnmail-split-fancy-with-parent.
 kg> If you have never used it, you won't miss it, but if you use it
 kg> now I'm guessing you will miss it dearly.

 >> I have been using it and I would miss it dearly. I'm VERY sure of
 >> that. :-)

 kg> He he.  Well, I think that the plus addressing trick will be
 kg> almost as good.

Maybe. But I think it's more work to maintain, has more files and also
I'm using mail splitting to get rid of duplicates. 

So things seem to be good the way they are. :) 

Once nnmaildir is stable & supports mail splitting, I'll definitely
give it a try. 

Regards,
                Georg

-- 
Georg C. F. Greve                                       <greve@gnu.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

Re: nnmail-split-fancy-with-parent (Was: Question about mail archive)

[Mats Löfdahl]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On 10 Apr 2001, Mats Löfdahl wrote:
> 
> > One thing I noticed is that it does not seem aware of renaming of
> > groups.
> 
> Working around this is simple: a string replace in ~/.nnmail-cache
> (then restarting Gnus) will do. It's not clear to me, however, what
> a real solution should look like. Thoughts?

Here are a couple of thoughts:

1. Make the group renaming function check the cache and change the
   lines that are relevant to the current renaming.

2. Provide a command that generates a new cache. This would have the
   added benefit that also old (as in "before use of
   nnmail-split-fancy-with-parent was added") messages could make it
   into the cache.

3. If 2. worked on a per group basis, it could also be used for 1. And
   there could be another command that called it for every mail group.

Beware that I don't really know what I'm talking about when it comes
to Gnus code development...

-- 
 Mats Löfdahl

Re: nnmail-split-fancy-with-parent (Was: Question about mail archive)

[Doug Alcorn]

Mats Löfdahl <mats_lofdahl@bigfoot.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
> > However, that way you might miss nnmail-split-fancy-with-parent. If
> > you have never used it, you won't miss it, but if you use it now I'm
> > guessing you will miss it dearly.
> 
> That comment made me go ahead and try it. It really seems very useful
> and I'd been wanting to for some time but never got around to it.
> 

OK, so now I went looking for documentation on this.  I'm running Gnus
5.8.8.  C-h f shows there is no documentation on that function.  And
the index of the Gnus info pages don't have an entry either.  Can I
get a pointer?
-- 
 (__) Doug Alcorn (mailto:doug@lathi.net http://www.lathi.net)
 oo / PGP 02B3 1E26 BCF2 9AAF 93F1  61D7 450C B264 3E63 D543
 |_/  If you're a capitalist and you have the best goods and they're
      free, you don't have to proselytize, you just have to wait. 

Re: nnmail-split-fancy-with-parent (Was: Question about mail archive)

[Kai Großjohann]

On 10 Apr 2001, Mats Löfdahl wrote:

> 1. Make the group renaming function check the cache and change the
>    lines that are relevant to the current renaming.

That makes sense.  It's not easy to add old messages to .nnmail-cache,
since we only know their message id, and then you'd have to go through
_all_ groups, showing _all_ messages.

kai
-- 
Be indiscrete.  Do it continuously.

Re: nnmail-split-fancy-with-parent (Was: Question about mail archive)

[Kai Großjohann]

On 10 Apr 2001, Doug Alcorn wrote:

> OK, so now I went looking for documentation on this.  I'm running
> Gnus 5.8.8.  C-h f shows there is no documentation on that function.
> And the index of the Gnus info pages don't have an entry either.
> Can I get a pointer?

In my info file, the node `Fancy Mail Splitting' contains this:

/----
|    `nnmail-split-fancy-with-parent' is a function which allows you to
| split followups into the same groups their parents are in.  Sometimes
| you can't make splitting rules for all your mail.  For example, your
| boss might send you personal mail regarding different projects you are
| working on, and as you can't tell your boss to put a distinguishing
| string into the subject line, you have to resort to manually moving the
| messages into the right group.  With this function, you only have to do
| it once per thread.
| 
|    To use this feature, you have to set `nnmail-treat-duplicates' to a
| non-nil value.  And then you can include
| `nnmail-split-fancy-with-parent' using the colon feature, like so:
|      (setq nnmail-split-fancy
|            '(| (: nnmail-split-fancy-with-parent)
|                ;; other splits go here
|              ))
| 
|    This feature works as follows: when `nnmail-treat-duplicates' is
| non-nil, Gnus records the message id of every message it sees in the
| file specified by the variable `nnmail-message-id-cache-file', together
| with the group it is in (the group is omitted for non-mail messages).
| When mail splitting is invoked, the function
| `nnmail-split-fancy-with-parent' then looks at the References (and
| In-Reply-To) header of each message to split and searches the file
| specified by `nnmail-message-id-cache-file' for the message ids.  When
| it has found a parent, it returns the corresponding group name.  It is
| recommended that you set `nnmail-message-id-cache-length' to a somewhat
| higher number than the default so that the message ids are still in the
| cache.  (A value of 5000 appears to create a file some 300 kBytes in
| size.)  When `nnmail-cache-accepted-message-ids' is non-`nil', Gnus
| also records the message ids of moved articles, so that the followup
| messages goes into the new group.
| 
\----

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> If I wasn't about to migrate to nnimap, I think I'd consider going
> to nnmaildir.

Well, some of the things nnmaildir does could be added to other
backends without too much trouble, I think.  Especially since nnimap
already stores marks, it could renumber articles for each server-open;
it'd just have to replace the mark ranges entirely in -update-info
instead of making small changes.  And the always-marks group parameter
really belongs in Gnus proper, not in backends - putting it in
nnmaildir is sort of a proof-of-concept.


paul

Re: Question about mail archive

[Paul Jarc]

"Georg C. F. Greve" <greve@gnu.org> writes:
>  pj> It isn't part of the Gnus distribution.
>  pj> <URL:http://multivac.cwru.edu/nnmaildir/>
> 
> Okay, that explains it. Any chance it'll be put into the main
> distribution at some point? 

I asked that once, got no response, and haven't investigated further.
I think the main advantage of having a backend in the distribution is
visibility - so a reference in the distribution might be just as good,
and it wouldn't require sorting out copyright issues.

>  pj> I guess I'll put nnmaildir-save-mail on the todo list, then. :)
> 
> :-)))))
> 
> I know from a very 

Unfinished thought?


paul

Re: Question about mail archive

[Paul Jarc]

Karl Kleinpaste <karl@charcoal.com> writes:
> prj@po.cwru.edu (Paul Jarc) writes:
> > The new version uses one file per message for NOV data
> 
> I have to observe that the whole point of the development of NNTP's
> XOVER facility is because news servers were suffering so badly in the
> face of user agents entering a group and wanting header data for
> hundreds of articles at a time, requiring opening hundreds of article
> files in order to find those headers.

Hm.  Well, there are some differences here.  An nnmaildir group has
only one user, not hundreds, or however many an NNTP server has to
deal with.  Maildirs already lean toward small files and large
directories, so users already have a motivation to use ReiserFS (or
another fs with similar strengths); the new version will just provide
more motivation, and take greater advantage of those strengths. :)

In the documentation I haven't written yet, I'm going to explain what
sort of situation nnmaildir works best with.  nnmaildir may not be as
general-purpose as some others, but at least people should be able to
figure out whether it will work well for them.


paul

Re: nnmail-split-fancy-with-parent (Was: Question about mail archive)

[Mats Löfdahl]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On 10 Apr 2001, Mats Löfdahl wrote:
> 
> > 1. Make the group renaming function check the cache and change the
> >    lines that are relevant to the current renaming.
> 
> That makes sense.  It's not easy to add old messages to .nnmail-cache,
> since we only know their message id, and then you'd have to go through
> _all_ groups, showing _all_ messages.

Will old messages be deleted from the cashe or will it keep data from
all messages if you add it from when you start using Gnus for the
first time? In the latter case it would probably be nice to be able to
include the already existing messages if you don't start fresh.

You can always start it just before you go to bed...

-- 
 Mats Löfdahl

Re: nnmail-split-fancy-with-parent (Was: Question about mail archive)

[Kai Großjohann]

On 10 Apr 2001, Mats Löfdahl wrote:

> Will old messages be deleted from the cashe or will it keep data
> from all messages if you add it from when you start using Gnus for
> the first time? In the latter case it would probably be nice to be
> able to include the already existing messages if you don't start
> fresh.

nnmail-message-id-cache-length gives a number of message ids that will
be kept in the cache.  Older ones will be deleted.

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Samuel Padgett]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> However, that way you might miss nnmail-split-fancy-with-parent.

Hmm.  Shouldn't this function have a docstring?  It doesn't in my Gnus
(oGnus v0.01).

Sam
-- 
Room service?  Send up a larger room.
                -- Groucho Marx

Re: Question about mail archive

[Kai Großjohann]

On 10 Apr 2001, Samuel Padgett wrote:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
>> However, that way you might miss nnmail-split-fancy-with-parent.
> 
> Hmm.  Shouldn't this function have a docstring?  It doesn't in my
> Gnus (oGnus v0.01).

Yes, it should.  But at least there's an entry in the info file...  Do
you think the whole shebang should go in the docstring, or a shorter
version of it?

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> On 10 Apr 2001, Samuel Padgett wrote:
> > Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> >> However, that way you might miss nnmail-split-fancy-with-parent.
> > 
> > Hmm.  Shouldn't this function have a docstring?  It doesn't in my
> > Gnus (oGnus v0.01).
> 
> Yes, it should.  But at least there's an entry in the info file...  Do
> you think the whole shebang should go in the docstring, or a shorter
> version of it?

Shorter, I think.  Is it possible to have a link in the docstring that
points to the info node?  I'm guessing not, but the docstring should
at least say which info node has the full story.


paul

Re: Question about mail archive

[Kai Großjohann]

On 11 Apr 2001, Paul Jarc wrote:

> Shorter, I think.  Is it possible to have a link in the docstring
> that points to the info node?  I'm guessing not, but the docstring
> should at least say which info node has the full story.

./done, fix in CVS

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Steinar Bang]

>>>>> prj@po.cwru.edu (Paul Jarc):

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

>> If I wasn't about to migrate to nnimap, I think I'd consider going
>> to nnmaildir.

> Well, some of the things nnmaildir does could be added to other
> backends without too much trouble, I think.  Especially since nnimap
> already stores marks, it could renumber articles for each
> server-open;

Does that mean nnimap would work with the qmail/courier combination?

I have a friend who had to trade Gnus for Mutt, because courier kept
renumbering the articles on the server.

I have had this happen to myself occasionally on Exchange servers.
The only way out of it, is to store away the group parameters
somewhere safe, delete the group in question, stop and start Gnus, and
re-subscribe to the group (the marks in the group are preserved), and
add your group parameters.

This works, but gets tedious if it happens all the time.

Re: Question about mail archive

[Kai Großjohann]

On 14 Apr 2001, Steinar Bang wrote:

> I have had this happen to myself occasionally on Exchange servers.
> The only way out of it, is to store away the group parameters
> somewhere safe, delete the group in question, stop and start Gnus,
> and re-subscribe to the group (the marks in the group are
> preserved), and add your group parameters.

What does M-x gnus-group-clear-data RET on the group do in that case?

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[Paul Jarc]

Steinar Bang <sb@metis.no> writes:
> >>>>> prj@po.cwru.edu (Paul Jarc):
> > Well, some of the things nnmaildir does could be added to other
> > backends without too much trouble, I think.  Especially since nnimap
> > already stores marks, it could renumber articles for each
> > server-open;
> 
> Does that mean nnimap would work with the qmail/courier combination?

It could.  The backend needs to keep a list in memory associating
article numbers with persistent message idetifiers - that's the price.
When scanning for articles, you take all the ones that don't already
have numbers assigned, sort them from earliest delivery time to
latest, and then number them sequentially, starting from wherever you
left off the last time you scanned.

nnimap-request-update-info would need to get the marks from the
server, translate message identifiers into article numbers, and
completely replace the marks in the group info, since articles are
very likely to have different numbers compared to the last time the
server was opened.  This is how nnmaildir does it, anyway.

But nnmaildir also does some optimizations - e.g., it rescans the mark
directories on disk only if the modtime has changed since the last
scan.  I don't know if IMAP allows anything analogous.  If not, this
might not be feasible for nnimape, since redoing the marks every time
you scan for new mail can slow you down quite a bit.


paul

Re: Question about mail archive

[Kai Großjohann]

On 14 Apr 2001, Paul Jarc wrote:

> But nnmaildir also does some optimizations - e.g., it rescans the
> mark directories on disk only if the modtime has changed since the
> last scan.  I don't know if IMAP allows anything analogous.  If not,
> this might not be feasible for nnimape, since redoing the marks
> every time you scan for new mail can slow you down quite a bit.

IMAP has a uidvalidity value for each group.  As long as that value
stays the same, you don't need to rescan since you know that the
article numbers have stayed the same.  When uidvalidity changes,
the numbers might (!) have changed and so nnimap needs to do a rescan.

I guess the worst that could happen is that the uidvalidity value
changes every time a message is deleted from a group.

kai
-- 
Be indiscrete.  Do it continuously.

Re: Question about mail archive

[simon]

Steinar Bang <sb@metis.no> writes:

> Does that mean nnimap would work with the qmail/courier combination?
> 
> I have a friend who had to trade Gnus for Mutt, because courier kept
> renumbering the articles on the server.

Do you know if that is a "vanilla" qmail/courier installation?  I
think I've heard several people using nnimap against Courier without
problems.

> The only way out of it, is to store away the group parameters
> somewhere safe, delete the group in question, stop and start Gnus, and
> re-subscribe to the group (the marks in the group are preserved), and
> add your group parameters.
> 
> This works, but gets tedious if it happens all the time.

Agreed.  I only wished it happened to me more often (it never does),
so I would get bugged about enough to fix it.

(Isn't it enough to remove the uidvalidity group parameter though?)

Re: Question about mail archive

[Steinar Bang]

>>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann):

> On 14 Apr 2001, Steinar Bang wrote:

>> I have had this happen to myself occasionally on Exchange servers.
>> The only way out of it, is to store away the group parameters
>> somewhere safe, delete the group in question, stop and start Gnus,
>> and re-subscribe to the group (the marks in the group are
>> preserved), and add your group parameters.

> What does M-x gnus-group-clear-data RET on the group do in that case?

Don't know.  Maybe I'll try that next time exchange messes things up
for me?  It hasn't done it for half a year now, though.

Re: Question about mail archive

[Steinar Bang]

>>>>> simon@josefsson.org:

>> The only way out of it, is to store away the group parameters
>> somewhere safe, delete the group in question, stop and start Gnus,
>> and re-subscribe to the group (the marks in the group are
>> preserved), and add your group parameters.

>> This works, but gets tedious if it happens all the time.

> Agreed.  I only wished it happened to me more often (it never does),
> so I would get bugged about enough to fix it.

> (Isn't it enough to remove the uidvalidity group parameter though?)

Nope.  At least, it didn't the last time it happened to me.  However,
that was quite a different Gnus from what I'm running now, so it may
be enough these days.

I think it was either you or Kai that said it wasn't enough, and why.
(I tried it out for myself, though.  It wasn't enough...:-) )

Re: Question about mail archive

[Bjørn Mork]

simon@josefsson.org writes:
> Steinar Bang <sb@metis.no> writes:
> 
> > Does that mean nnimap would work with the qmail/courier combination?
> > 
> > I have a friend who had to trade Gnus for Mutt, because courier kept
> > renumbering the articles on the server.
> 
> Do you know if that is a "vanilla" qmail/courier installation?  I
> think I've heard several people using nnimap against Courier without
> problems.

At least I am. I am using nnimap against two Courier servers, and have
never experienced this problem on any of them.


Bjørn
-- 
Why, my punk haircut is pretty good!