Re: 2 borkage detected

["M . Thielker" <balsa t-data com>]

Hi,

On 2001.08.18 07:51 Ali Akcaagac wrote:
> - delete one message. now go to the trash and undelete it. the
>   number in the trash entry gets increased but the file doesnt
>   get undeleted (i remember someone reported this already)...
> 
>   ... together with this i've detected that deleted messages should
>   get the 'trashcan' symbol applied to the 'S' field of the clist.
>   (look at my previous *.jpg with the new icons shown, there where
>   you see the envelopes, there should be an trashcan when the
>   message was moved into the trashcan.
> 
>   at least this function was in the sourcecode. here an example.....

I have looked into this and found that there is a signal "set-deleted",
however, this signal is never emitted. It appears as if that functionality
was put into libbalsa to support client-server architectures where the
server itself would support such a thing.
It would be useful for something like operationg on an IMAP folder and
synchronizing the server later, like with a notebook computer or somesuch.
The current implementation of IMAP does not need it, cannot use it, as a
matter of fact, without some major code-bending.
While I propose to keep the ability to display the trashcan icon, I would
suggest the following method to fix the undelete problem once and for all,
and for all message store architectures:
Deleting a message will _move_ the message to the trash can, as it does now.
This is intuitive, it is not intuitive (to me) so see a message I have
already deleted in my inbox.
In the course of that move, a header X-Balsa-Original-Mailbox-URI: will be
added to the message, containing the URL of the mailbox the message was
deleted from.
On undelete, the information from this new header is used to restore the
message. The advantage is that the original mailbox will be preserved no
matter where the trash can is stored, local or remote. Memory based record
keeping would not be a good idea because it would not allow undeleting of
messages deleted in prior sessions and keeping track in a separate file
would fail if something like procmail or another mail ua modifies the
trashcan.
In order for this to work, forwarding of deleted messages _must_ be disabled
and the header _should_ be removed when a message is undeleted and restored
to its prior location.
Possible pitfalls are: trying to restore a message to a deleted folder.
Solution: put in inbox intead. Also, changing the trash can folder while
it's not empty. Solution: just ignore, in the worst case that could possibly
result in the new header field being included in a message transmitted over
the network. Finally, marking a folder as trash can that is not empty.
Solution: When trying to undelete a message that does not have that special
header, put it into the inbox.

Comments?

Melanie