The notorious outbox



Hi all,

I think it's a good idea to split out the outbox-issue from the review thread, I can't even trace/reference it there anymore. ;)

Being a pure IMAP-user like Joe I raised this topic long time ago, and made some progress on my thoughts since then.

With the current implementation it's not possible to assign it to a remote folder, I had a GUI-patch for this (in Bugzilla, probably outdated) and it failed on my server, which works fine otherwise.

But it's not the solution. Let's analyze when the outbox is needed by a user, and what renders it different from other mailboxes:

- no one cares for it as long as it's empty
- you'll never move messages into it
- it is important to see if messages are queued
- remote storage is a very difficult issue I realized

For a user, the outbox is just the queue, needed only in two cases:
- offline usage of the MUA
- SMTP-server is down

The fact that balsa uses it for instant sendings is wrong, it should have a hidden cache, or pass it directly to libesmtp or whatever. Another potential problem is that balsa will send all queued messages if you send one instantly. Apart from being unexpected by the user (he only clicked "send" on one message), it will lead to trouble if you implement different identities with different SMTP-accounts.

So I'd suggest to clearly separate the cache for one message being sent right now and the queue, which should only be a queue.

Now the interesting question is, whether the queue should be local or remote. I have no idea, I'll just provide two mutually exclusive scenarios which prove that there is no easy solution:

- assume you've composed a message at PC1 and want to send it, the SMTP-server is down, you'd like to send it later of course, when you are at PC2 -> remote queue

- assume this message uses a SMTP-account only accessible from and configured at PC1, if you are on PC2, the SMTP-account isn't usable at all, an IMAP-server doesn't know anything about sending, so why to store messages there? -> local queue

bye,

Darko



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]