Proposal/Request for feature for splitting to FQ groups

Proposal/Request for feature for splitting to FQ groups

[Soren Dayton]

So I was playing with splitting again (this is a hobby of mine) and I
would really like to be able to split from my nnml backend into an
nnimap mailbox.  This would be really, really nice for me.

So my question is how?  This is a proposal for how it might work.

Basically, the idea is that nnmail-split-methods/nnimap-split-rule
should be able to return something of the form:


        nnml:foo.bar.baz

or

        nnimap:foo.bar.baz

or whatever.

The problem seems to me to be distinguishing the gnus-select-method
case, from every other case.  That is, consider that I might have an
nnml group alt.emacs.religion.  Currently, if nnmail-split-methods
produces alt.emacs.religion, then it goes to nnml:alt.emacs.religion.
But if you could split into a different server, why isn't it going to
alt.emacs.religion (other than its really annoying behavior)

It seems to me that the issue is that everything that is not fully
qualified (and thus nntp:alt.emacs.religion in this case) would go to
the currently running server.

That is, more generally,

        `gnus-select-method':foo == foo  

which would be a special case, and everything else would behave
normally.  Unless there are re-entry problems, this _should_ be
doable, shouldn't it?

I haven't looked at the code, but if the re-entry problems are not
there, would this be an ok thing to add to the distribution?

Thanks
Soren

Re: Proposal/Request for feature for splitting to FQ groups

[William M. Perry]

Soren Dayton <csdayton@cs.uchicago.edu> writes:

> So I was playing with splitting again (this is a hobby of mine) and I
> would really like to be able to split from my nnml backend into an nnimap
> mailbox.  This would be really, really nice for me.

Ooooh oooh me too!

Please please please?!?!?! :)

I volunteer lots of beer if this gets into pgnus before it gets a 'real'
number and we don't add any more features.  'GCC' can do this kind of
thing, so why not the splitting code? :)

-bp

Re: Proposal/Request for feature for splitting to FQ groups

[Soren Dayton]

wmperry@aventail.com (William M. Perry) writes:

> Soren Dayton <csdayton@cs.uchicago.edu> writes:
> 
> > So I was playing with splitting again (this is a hobby of mine) and I
> > would really like to be able to split from my nnml backend into an nnimap
> > mailbox.  This would be really, really nice for me.
> 
> Ooooh oooh me too!
> 
> Please please please?!?!?! :)
> 
> I volunteer lots of beer if this gets into pgnus before it gets a 'real'
> number and we don't add any more features.  'GCC' can do this kind of
> thing, so why not the splitting code? :)

So, I've thought about it some more, and there may be good reasons `why
not the splitting code'.  I don't see a good failure behavior.  What
happens if the method cannot be brought up (it is on a down file server,
the imap server isn't up, I just deleted the directory that stores the
messages for that method, etc.).

For Gcc, it's easy because it's the user's problem.  Gnus beeps at me,
and I go fix it or change it or whatever.

But if I've been on vacation for a month, I start up gnus, and go take a
shower (after all, bbdb splitting ain't fast) and it starts splitting.
And my imap server (which I am splitting messages into) is down.  I'm
screwed.  Stick it somewhere where I have to split 500 messages by hand?
Not me.  Stick it in the crash box?  Eep.

What would the right behavior be here?

Soren

Re: Proposal/Request for feature for splitting to FQ groups

[William M. Perry]

Soren Dayton <csdayton@cs.uchicago.edu> writes:

> wmperry@aventail.com (William M. Perry) writes:
> 
> > Soren Dayton <csdayton@cs.uchicago.edu> writes:
> > 
> > > So I was playing with splitting again (this is a hobby of mine) and I
> > > would really like to be able to split from my nnml backend into an nnimap
> > > mailbox.  This would be really, really nice for me.
> > 
> > Ooooh oooh me too!
> > 
> > Please please please?!?!?! :)
> > 
> > I volunteer lots of beer if this gets into pgnus before it gets a 'real'
> > number and we don't add any more features.  'GCC' can do this kind of
> > thing, so why not the splitting code? :)
> 
> So, I've thought about it some more, and there may be good reasons `why
> not the splitting code'.  I don't see a good failure behavior.  What
> happens if the method cannot be brought up (it is on a down file server,
> the imap server isn't up, I just deleted the directory that stores the
> messages for that method, etc.).
> 
> For Gcc, it's easy because it's the user's problem.  Gnus beeps at me,
> and I go fix it or change it or whatever.

That's still not very nice. :)

> But if I've been on vacation for a month, I start up gnus, and go take a
> shower (after all, bbdb splitting ain't fast) and it starts splitting.
> And my imap server (which I am splitting messages into) is down.  I'm
> screwed.  Stick it somewhere where I have to split 500 messages by hand?
> Not me.  Stick it in the crash box?  Eep.
> 
> What would the right behavior be here?

Stick it somewhere where you can easily respool the entire mailbox with a
single keystroke (or two or three).

-Bill P.

Re: Proposal/Request for feature for splitting to FQ groups

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

> I volunteer lots of beer if this gets into pgnus before it gets a 'real'
> number and we don't add any more features.  'GCC' can do this kind of
> thing, so why not the splitting code? :)

Splitting to several servers makes things much, much more complex.  I
think it would make more sense to add a `gnus-group' mail source, so
that, for instance, you first allow nnml to split all the mail, and
then you have nnbabyl split the mail using some of the nnml groups as
sources.  Or something like that.

I think.

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

Re: Proposal/Request for feature for splitting to FQ groups

[Kai.Grossjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Splitting to several servers makes things much, much more complex. 

In what way is it more complex than the status quo?  I mean, Gnus
reads a message, then decides where it should go.  What difference
does it make whether or not all target groups are on the same server?

I imagined Gnus to just call nnchoke-request-accept-article for the
appropriate server...

kai
-- 
Life is hard and then you die.

Re: Proposal/Request for feature for splitting to FQ groups

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> In what way is it more complex than the status quo?  I mean, Gnus
> reads a message, then decides where it should go.  What difference
> does it make whether or not all target groups are on the same server?

To speed things up, the splitting usually goes in three phazes:  1)
set-up, 2) saving articles, 3) saving control structures.
Multi-set-up and multi-control-structure-saving would require a
rewrite of quite a bit of the code, I think.

There's also the issue of what crossposting between various servers is 
supposed to mean.

Calling *-request-accept-article on all the messages would be
unacceptably slow.  Reeeally slow.

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

Re: Proposal/Request for feature for splitting to FQ groups

[Kai.Grossjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Calling *-request-accept-article on all the messages would be
> unacceptably slow.  Reeeally slow.

Hm.  Sounds like your suggestion of splitting to a group first then
resplitting that group to another backend sounds like a good choice,
then.

Or is it feasible to just "leave" a message during splitting?  Then
you could split in several steps: first you do all the nnml splitting,
then the nnimap splitting (on the messages which were "left" during
nnml splitting).

kai
-- 
Life is hard and then you die.

Re: Proposal/Request for feature for splitting to FQ groups

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Or is it feasible to just "leave" a message during splitting?  Then
> you could split in several steps: first you do all the nnml splitting,
> then the nnimap splitting (on the messages which were "left" during
> nnml splitting).

Hm.  I don't think that would fit into the current framework.

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