Gnus development mailing list
 help / color / mirror / Atom feed
From: prj@po.cwru.edu (Paul Jarc)
Subject: Re: B DEL is being treated as expiry?
Date: Tue, 23 Jul 2002 14:33:26 -0400	[thread overview]
Message-ID: <m3wurmthtf.fsf@multivac.cwru.edu> (raw)
In-Reply-To: <vxkbs8yfh9s.fsf@cinnamon.vanillaknot.com> (Karl Kleinpaste's message of "Tue, 23 Jul 2002 14:09:19 -0400")

Karl Kleinpaste <karl@charcoal.com> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> The backend interface must define how this is expressed, and all
>> backends must be made to conform to that specification.
>
> So make them conform.
>
> Why is this hard?

I never said it was hard.  I really don't think it is hard to fix the
backend interface documentation and then to fix the backends.

> I solved today's problem, so that things just plain *work* according
> to established intent -- so that -delete-article *stops making mistakes*.

It stops making mistakes *for you*.

> You have a view toward a different problem; feel free to solve that.

I'm looking at the more general case of the same problem, as well as a
different but related problem.

> I am of the opinion that this different problem is most readily solved
> merely by convincing the currently non-conforming backends to
> understand nnmail-expiry-target, plus adding 1 general function +
> keybinding to provide expire-right-now as well.

Currently, all backends conform equally well to the backend interface
spec (AFAIK).  The spec does not say that backends should delete
instead of expiring in any particular case, and the spec does not give
callers enough information to know (in general) how to tell backends
to delete instead of expiring.

And since your fix has not been installed AFAIK, all backends fail to
DTRT for B DEL.  If you say all backends should be fixed, I agree.
But I don't think your patch is the right way to do that.

>> g-s-d-a is not supposed to know the details of how backends decide
>> what to do with expirable articles; it's only supposed to know what
>> to pass to nnchoke-request-expire-articles.
>
> -delete-article doesn't know squat about anything to do with expiry at
> all -- it isn't *doing* expiry so it doesn't *care* about expiry,
> other than to turn it off unconditionally.

But it doesn't know how to do that via nn*-request-expire-articles.
The backend interace doesn't say that that's even possible at all.

> It sounds like the problem you have is that there exists any use of
> nnmail-expiry-target.  Feel free to redesign that, if the urge moves
> you, but I think you're working too hard.

No, I don't have a problem with that.  I have a problem with the
disconnect between the code and the documentation.  If the code does
not conform to the backend interface definition, such as by making
unwarranted assumptions about how to configure expiry behavior for all
backends, then the backend interface definition is worse than useless;
it's harmful, because it leads people to believe things that the code
does not agree with.

Ideally, I think it would be nice for all the expiry code to be
removed from the backend interface.  Given
nn*-request-{move,accept}-article, Gnus can do expiry itself, and more
uniformly than when backends do it themselves.

>> The problem isn't specific to nnmaildir; your fix is specific to
>> nnmail-derived backends.  I don't know, but I'd guess that it also
>> fails for nnimap.
>
> The fix is general with regard to _today's_ expectation that
> nnmail-expiry-target is the specified way to define expiry habits, by
> means of overriding any general expiry intention so that deletion, and
> only deletion, is what occurs.  gnus-request-expire-articles works
> this way, and -delete-article accommodates it.

I don't mind too much that those Gnus functions help the
nnmail-derived backends this way, although it's a bit ugly.  But the
fix for this problem should work for all backends, not just the nnmail
ones.  The expectation that n-e-t is the way to define expiry behavior
is itself derived from using nnmail-derived backends.  Other backends
exist and must be accounted for.

>> It isn't completely disjoint, because it's likely that we'll want to
>> use the same backend function for both purposes.  (Otherwise we'll
>> be duplicating a significant amount of code.)
>
> Please.  The totality of -delete-article is 40 lines.

I'm talking about nn*-request-expire-articles.  Separate
nn*-request-delete-articles functions would duplicate much of that
code, I think.

But we already have nn*-request-move-article, which can be used to
remove articles instead of expiring them.  Why don't we change B DEL
to use that?  That should work for all backends.

> You can find numerous examples of duplicated code in Gnus much
> larger than that.

That doesn't sound like a good reason for adding more.


paul



  reply	other threads:[~2002-07-23 18:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-23 11:21 Karl Kleinpaste
2002-07-23 11:49 ` Kai Großjohann
2002-07-23 13:40   ` Josh Huber
2002-07-23 13:58   ` Nevin Kapur
2002-07-23 16:03   ` Karl Kleinpaste
2002-07-23 16:16     ` Paul Jarc
2002-07-23 16:23       ` Karl Kleinpaste
2002-07-23 16:36         ` Paul Jarc
2002-07-23 17:01           ` Karl Kleinpaste
2002-07-23 17:40             ` Paul Jarc
2002-07-23 18:09               ` Karl Kleinpaste
2002-07-23 18:33                 ` Paul Jarc [this message]
2002-07-24 15:44                   ` Kai Großjohann
2002-07-24 16:05                     ` Paul Jarc
2002-07-26 12:51               ` Simon Josefsson
2002-07-26 14:50                 ` Paul Jarc
2002-07-26 16:37                   ` Simon Josefsson
2002-07-26 16:48                     ` Paul Jarc
2002-07-26 18:33                       ` Simon Josefsson
2002-07-23 21:23       ` Nevin Kapur
2002-07-23 21:43         ` Paul Jarc
2002-07-24  2:08           ` Nevin Kapur

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3wurmthtf.fsf@multivac.cwru.edu \
    --to=prj@po.cwru.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).