Re: nnimap article editing

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 09 Oct 2008 16:58:51 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Ted Zlatanov <tzz@lifelogs.com> writes:
>> This, if implemented, would work for any backend that accepts articles,
>> not just nnimap.

DE> OK, so you're talking about implementing an alternative to article
DE> editing through delete-and-create, without touching nnimap at all? I
DE> understood the original posting to implement
DE> nnimap-request-replace-article, which would be necessary for editing
DE> articles in nnimap like e.g. in nnml groups, which just cannot be
DE> done for IMAP, at least not according to the specification given in
DE> the manual ("remove ARTICLE (which is a number) from GROUP and
DE> insert BUFFER there instead").

Right, it would be BACKEND-request-replace-or-supersede-article
(whatever name people like) which would fall back to
BACKEND-request-replace-article if that was available.

>> I don't see a problem with sorting or caching.  Expire the old article,
>> that's all.  The new one should have the same Message-ID but otherwise
>> can be completely different. 

DE> The problem I see is that the article number would change while the
DE> article is displayed. Hence, after editing, Gnus would have to at least
DE> quit the summary buffer, rescan the group, and then re-enter the summary
DE> to display the edited article. 

I think that's reasonable, and probably can be done faster once the
basic operation works reliably.

DE> Users who use the *-by-number functions for sorting will probably
DE> see edited articles as most recent, but that's indeed a small
DE> issue. 

I think it's actually the expected behavior--users would expect the sort
to be by modification time, not creation time.  We can use the registry
to link the Message-ID to the creation time if necessary, it's not hard,
but I doubt many will care.

DE> As for caching (and the agent), I don't know if they depend in any
DE> way on a mapping between UID and Message-ID? If not, it shouldn't be
DE> a problem. In any case, I admit having an article editing solution
DE> like this is better than none at all.

I think the only part of Gnus that really cares about the Message-ID is
the registry.  Everything else goes by article number (based on what
I've seen in the code).  Maybe someone that knows the agent and caching
can explain better.

Ted