mail splitting to another backend

mail splitting to another backend

[Ted Zlatanov]

Currently, we can't split to another backend, e.g. nnml from nnimap.
Can that be added, if the destination is prefixed appropriately?
Spooling locally, then moving the article would be acceptable but
probably no easier.

Thanks
Ted

Re: mail splitting to another backend

[Paul Jarc]

Ted Zlatanov <tzz@lifelogs.com> wrote:
> Currently, we can't split to another backend, e.g. nnml from nnimap.
> Can that be added, if the destination is prefixed appropriately?

I think mail splitting really ought to be redone.  It should be
controlled by Gnus proper rather than an individual select method.
(There's too much policy in backends generally.)  Splitting to
multiple select methods would go naturally with that.


paul

Re: mail splitting to another backend

[Ted Zlatanov]

On Thu, 17 Apr 2003, prj@po.cwru.edu wrote:
> I think mail splitting really ought to be redone.  It should be
> controlled by Gnus proper rather than an individual select method.
> (There's too much policy in backends generally.)  Splitting to
> multiple select methods would go naturally with that.

OK, so multiple splitting is not in the near future?  I'm OK with
that, I just want to know so I can write the registry
split-with-parent function.

There's only two places where splitting is done, AFAIK: nnmail and
nnimap splitting (regular and fancy).

Ted

Re: mail splitting to another backend

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Currently, we can't split to another backend, e.g. nnml from nnimap.

You can use an IMAP mail-source and split from it into nnml.

Perhaps a directory mail-source handles the other direction.

Re: mail splitting to another backend

[Paul Jarc]

Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Thu, 17 Apr 2003, prj@po.cwru.edu wrote:
>> I think mail splitting really ought to be redone.  It should be
>> controlled by Gnus proper rather than an individual select method.
>> (There's too much policy in backends generally.)  Splitting to
>> multiple select methods would go naturally with that.
>
> OK, so multiple splitting is not in the near future?

Well, the overhaul probably isn't.  It's possible someone will do just
the multiple-split part earlier.


paul

Re: mail splitting to another backend

[Ted Zlatanov]

On Thu, 17 Apr 2003, jas@extundo.com wrote:
> You can use an IMAP mail-source and split from it into nnml.

How?  Using "nnml+private:mail" inside nnimap-split-fancy didn't work,
for instance (it created an IMAP folder with that name).

> Perhaps a directory mail-source handles the other direction.

I tested directing the nnmail split to nnimap, and that failed as
well (creating a directory under ~/Mail with the "nnimap+..." name).

Thanks
Ted

Re: mail splitting to another backend

[Paul Jarc]

Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Thu, 17 Apr 2003, jas@extundo.com wrote:
>> You can use an IMAP mail-source and split from it into nnml.
>
> How?  Using "nnml+private:mail" inside nnimap-split-fancy didn't work,
> for instance (it created an IMAP folder with that name).

Simon isn't saying that the syntax we want already works.  The mail
splitting would have to be done by the nnml select method
(nnml-get-new-mail t), referring to nnml groups without their
prefixes, but it could use IMAP as a mail-source.

>> Perhaps a directory mail-source handles the other direction.
>
> I tested directing the nnmail split to nnimap, and that failed as
> well (creating a directory under ~/Mail with the "nnimap+..." name).

For that, the nnimap select method would have to do the splitting; it
would refer to nnimap groups without their prefixes.

Doing it both ways in the same configuration would probably require
different values for mail-sources during the two splits (possible, or
not?), or carefully naming groups the same way on the two servers.


paul

Re: mail splitting to another backend

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 17 Apr 2003, jas@extundo.com wrote:
>> You can use an IMAP mail-source and split from it into nnml.
>
> How?  Using "nnml+private:mail" inside nnimap-split-fancy didn't work,
> for instance (it created an IMAP folder with that name).

(setq mail-sources
      '(imap :server "mail.example.org" :predicate "1:*" :mailbox "INBOX.tonnml"))

This would fetch all messages from INBOX.tonnml and split them using
nnmail, and there you should be able to split the into nnml.

>> Perhaps a directory mail-source handles the other direction.
>
> I tested directing the nnmail split to nnimap, and that failed as
> well (creating a directory under ~/Mail with the "nnimap+..." name).

I take back my idea -- nnimap cannot split mail from mail-sources,
only from a IMAP mailbox.  This is probably not very difficult to fix,
though.  Just replace the part that fetches mail from the INBOX,
before it is splitted, with some code that gets mail from a
mail-source.  But to not interfer with normal mail-sources, I think
this would mean adding a nnimap-mail-sources.

Re: mail splitting to another backend

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> I take back my idea -- nnimap cannot split mail from mail-sources,
> only from a IMAP mailbox.  This is probably not very difficult to fix,
> though.  Just replace the part that fetches mail from the INBOX,
> before it is splitted, with some code that gets mail from a
> mail-source.  But to not interfer with normal mail-sources, I think
> this would mean adding a nnimap-mail-sources.

I think there is a mechanism already for having different sources for
each server.  Maybe it works by adding a server parameter?

A new variable nnimap-mail-source wouldn't help those who have two
nnimap servers ;-)

-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: mail splitting to another backend

[Ted Zlatanov]

On Fri, 18 Apr 2003, jas@extundo.com wrote:
> I take back my idea -- nnimap cannot split mail from mail-sources,
> only from a IMAP mailbox.  This is probably not very difficult to
> fix, though.  Just replace the part that fetches mail from the
> INBOX, before it is splitted, with some code that gets mail from a
> mail-source.  But to not interfer with normal mail-sources, I think
> this would mean adding a nnimap-mail-sources.

While your idea has its uses, I'm not sure it helps here.  What I want
is very simple, and can't be achieved for the general case with the
one-time cross-splitting you demonstrate.  I just want users to say
"split to destination nnxyz+abc:mail" in nn{mail|imap}-split-fancy and
have it work, like users would reasonably expect since the rest of
Gnus works with this convention.

What's below is generic enough that any backend can use it when
splitting, not just nnmail/nnimap - I only looked at nnmail.el though
so please correct any inaccuracies.

1) if nnmail-article-group returns a normal (non-prefixed) group name
   do normal splitting (incidentally, should the ":" character be
   allowed in group names?)

2) if nnmail-article-group returns a prefixed group name outside the
   current server, put the message in a "split-queue" group and
   remember the article number and the destination, perhaps with an
   extra header inside the article body to make the destination
   persistent even if the queue redistribution fails.  Once mail
   splitting is done, the queue group is redistributed by moving the
   articles to their destination; this is fairly easy and any failed
   moves will simply remain in the queue group until the user creates
   the destination or deletes the articles.

3) if nnmail-article-group returns a prefixed group name that refers to
   our own server (I have not yet figured out how to detect this),
   either strip off the prefix and proceed as in (1) or just do (2),
   it shouldn't make a difference.

I'd be happy to help implement the above, but I doubt I can do the
whole thing on my own.

Thanks
Ted

server parameter vs. server variable (was: mail splitting to another backend)

[Reiner Steib]

On Fri, Apr 18 2003, Kai Großjohann wrote:

> Maybe it works by adding a server parameter?

Most people here use the term `server parameter' instead of `server
variable' as the manual does, see (info "(gnus)Server Variables").
The only match on `server parameter' is in the new nnmaildir node.

Any objection against the following patch?

--8<---------------cut here---------------start------------->8---
@@ -12191,6 +12191,8 @@
 
 @node Server Variables
 @subsection Server Variables
+@cindex server variables
+@cindex server parameters
 
 One sticky point when defining variables (both on back ends and in Emacs
 in general) is that some variables are typically initialized from other
@@ -12215,6 +12217,7 @@
       (nnml-newsgroups-file "~/my-mail/newsgroups"))
 @end lisp
 
+Server variables are often called ``server parameters''.
 
 @node Servers and Methods
 @subsection Servers and Methods
@@ -14811,7 +14814,7 @@
 an nnmaildir group.  The results might happen to be useful, but that
 would be by chance, not by design, and the results might be different
 in the future.  If your split rules create new groups, remember to
-supply a @code{create-directory} server parameter.
+supply a @code{create-directory} server variable.
 @end table
 
 @subsubsection Group parameters
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: mail splitting to another backend

[Paul Jarc]

Ted Zlatanov <tzz@lifelogs.com> wrote:
> 2) if nnmail-article-group returns a prefixed group name outside the
>    current server, put the message in a "split-queue" group

Why the queue?  Couldn't the article be immediately stored in the
proper destination group?


paul

Re: mail splitting to another backend

[Ted Zlatanov]

On Fri, 18 Apr 2003, prj@po.cwru.edu wrote:
> Ted Zlatanov <tzz@lifelogs.com> wrote:
>> 2) if nnmail-article-group returns a prefixed group name outside
>>    the current server, put the message in a "split-queue" group
> 
> Why the queue?  Couldn't the article be immediately stored in the
> proper destination group?

I don't know, I assumed that there was something magical about the
splitting environment that makes it imperative to use groups local to
the current server.

Ted

Re: server parameter vs. server variable

[Paul Jarc]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> wrote:
> The only match on `server parameter' is in the new nnmaildir node.

Oops.  No objections to the change.


paul

Re: server parameter vs. server variable

[Kai Großjohann]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> Any objection against the following patch?

It's a good idea.

Does the rest of the manual also use ``quotes'' or does it use `quotes'?

-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: server parameter vs. server variable

[Jesper Harder]

kai.grossjohann@gmx.net (Kai Großjohann) writes:

> Does the rest of the manual also use ``quotes'' or does it use
> `quotes'?

``quotes''.  But I think @dfn is the right mark up in this case, i.e.

  Server variables are often called @dfn{server parameters}.

texinfo markup fixes (was: server parameter vs. server variable)

[Reiner Steib]

On Sun, Apr 20 2003, Jesper Harder wrote:

> But I think @dfn is the right mark up in this case, i.e.
>
>   Server variables are often called @dfn{server parameters}.

Committed.  Shouldn't we have a @dfn{Server variables} in (info
"(gnus)Server Variables") too?  Where?

BTW: I think @sc{...} should be replaced with @acronym or @var in most
places.  Opinions?

@sc{gnus 4.1} @sc{gnus} @sc{html} @sc{imapd} @sc{imap} @sc{mime}
@sc{nntp} @sc{oed} @sc{pem} @sc{pgp/mime} @sc{rmail}
@sc{s/mime} @sc{semi} @sc{smtp} @sc{soup} @sc{ssl} @sc{url} @sc{vm}

... should all be changed to @acronym, I think.

@sc{your@@email.address} should be @var{your@@email.address}.

I'm unsure about the following:

@sc{Cc:} @sc{Note:} @sc{To:} ?

@sc{create} @sc{append} @sc{nov} @sc{xover} @sc{head} @sc{mode reader}

Should we use @command{CREATE} or @code?

@sc{marks} ("any @sc{marks} files") ?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: texinfo markup fixes

[Jesper Harder]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> BTW: I think @sc{...} should be replaced with @acronym or @var in most
> places.  Opinions?
>
> @sc{gnus 4.1} @sc{gnus} 

I don't think those are acronyms.

> @sc{rmail}

rmail.texi uses "Rmail", so that's probably the right way to write it.

> @sc{html} @sc{imapd} @sc{imap} @sc{mime} @sc{nntp} @sc{oed} @sc{pem}
> @sc{pgp/mime}  @sc{s/mime} @sc{semi} @sc{smtp} @sc{soup}
> @sc{ssl} @sc{url} @sc{vm}
>
> ... should all be changed to @acronym, I think.

I agree.  

> @sc{your@@email.address} should be @var{your@@email.address}.

Either @samp or @var.

> I'm unsure about the following:
>
> @sc{Cc:} @sc{Note:} @sc{To:} ?

@samp{Cc:}, @samp{To:}, Note: or maybe @emph{Note:}.

Re: texinfo markup fixes

[François Pinard]

[Jesper Harder]

> > @sc{your@@email.address} should be @var{your@@email.address}.

> Either @samp or @var.

Or probably better: @email

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: texinfo markup fixes

[Jesper Harder]

pinard@iro.umontreal.ca (François Pinard) writes:

> [Jesper Harder]
>
>> > @sc{your@@email.address} should be @var{your@@email.address}.
>
>> Either @samp or @var.
>
> Or probably better: @email

No, @email is for an actual email address that you might want to contact
-- it creates a mailto: link in HTML and PDF output.

Re: texinfo markup fixes

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 567 bytes --]

[Jesper Harder]

> pinard@iro.umontreal.ca (François Pinard) writes:

> > [Jesper Harder]
> >
> >> > @sc{your@@email.address} should be @var{your@@email.address}.
> >
> >> Either @samp or @var.
> >
> > Or probably better: @email

> No, @email is for an actual email address that you might want to contact
> -- it creates a mailto: link in HTML and PDF output.

Oh, I see.  You are right then, sorry.  In that situation, I would use:

   @samp{@var{your}@@@var{email}.@var{address}}

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: mail splitting to another backend

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I don't know, I assumed that there was something magical about the
> splitting environment that makes it imperative to use groups local to
> the current server.

The splitting process is kinda optimized -- if you were splitting
naively to lots of groups, things would be a lot slower.  (Writing
.overview/active files repeatedly, etc.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: mail splitting to another backend

[Ted Zlatanov]

On Sun, 27 Apr 2003, larsi@gnus.org wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> I don't know, I assumed that there was something magical about the
>> splitting environment that makes it imperative to use groups local
>> to the current server.
> 
> The splitting process is kinda optimized -- if you were splitting
> naively to lots of groups, things would be a lot slower.  (Writing
> .overview/active files repeatedly, etc.)

OK, so going back to my suggestion of a queue group - what's wrong
with the suggestion?  Just put articles destined for a foreign group
in the queue group, and then move them out of the queue based on an
artificial header.  It won't disturb anything in the splitting
process.

It seems like it would be pretty easy to implement, too.

Ted

Re: mail splitting to another backend

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> OK, so going back to my suggestion of a queue group - what's wrong
> with the suggestion?  Just put articles destined for a foreign group
> in the queue group, and then move them out of the queue based on an
> artificial header.  It won't disturb anything in the splitting
> process.

A queue group sounds like it might be the solution; yes.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen