a default inbox annotation

David Faure dfaure at klaralvdalens-datakonsult.se
Wed Oct 6 11:41:51 CEST 2004

On Wednesday 06 October 2004 11:26, Martin Konold wrote:
> Well, it is not only about Outlook but also about Kontact. Look at my office I 
> have full IMAP access to my Kolab server but from some remote locations I can 
> do pop3 but not IMAP. 
> So currently I end up with mail duplication using only Kontact.
> (The IMAP kioslaves shows the messages in the IMAP INBOX. I tend to leave 
> messages in the inbox which need my attention later. When leaving the office 
> and using pop3 I again get the messages downloaded to my Kmail Inbox which is 
> _different_ from my Kolab INBOX. Such mail duplication is not nice)
I see.

Assuming pop preserves the UID, I _guess_ that you wouldn't have to re-download
mail via imap that you got via pop. But will pop also be clever enough to notice which
mail you already downloaded via IMAP?

> > > No, it would mean hiding the IMAP INBOX and only show the Kolab Inbox.
> > > Actually the current behavior is really confusing for many people as
> > > folder cannot be next to the IMAP INBOX but must be children of the IMAP
> > > INBOX.
> >
> > Wrong - you can use Prefix=/INBOX/ for this.
> What do you mean? What shall Joe User do?
You can try by typing "/INBOX" in the prefix lineedit of the dIMAP 
account configuration dialog box in kmail/kontact.
If this is a preferred layout for kolab2 we can make the wizard set it,
and Joe User won't have to do anything.

> Because people in different cultures might choose other names. 
Hmm, I thought the webgui knew the preferred language. OK, whatever.

> Actually I prefer explicit semantics (using an annotation) to implicit semantics 
Sure, never said the contrary.

OK, I understand the idea now - basically treating IMAP INBOX like a pop account:
as a way to download mail, but then it arrives into another folder.
*However* this is going to be awful for the user, because all the messages that
you download from your IMAP INBOX will have to be re-uploaded on the next sync,
since they are now in another folder!

Also, I doubt that it's a good idea to make this kind of fundamental change at this point.
Aren't we late already in the project? How will we ever get to the end of it in time,
if new requirements pop up every week?
Downloading mail via both POP and IMAP might be an interesting problem to solve,
but it isn't part of the proko2 specifications.

David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions

More information about the format mailing list