[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: [Kde-pim] IMAP namespaces
From:       Carsten Burghardt <burghardt () kde ! org>
Date:       2005-05-15 13:33:34
Message-ID: 200505151533.34921.burghardt () kde ! org
[Download RAW message or body]

Am Sonntag, 15. Mai 2005 13:53 schrieb Ingo Klöcker:
> On Sunday 15 May 2005 12:46, Carsten Burghardt wrote:
> > Am Sonntag, 15. Mai 2005 11:59 schrieb Adriaan de Groot:
> > > On Sunday 15 May 2005 01:11, Carsten Burghardt wrote:
> > > > Am Donnerstag, 12. Mai 2005 23:14 schrieb Adriaan de Groot:
> > > > > See, I _had_ a Folder Prefix set for my IMAP folders: Mail/ ;
> > > > > it even says so in the config file:
> > > > >
> > > > > prefix=/Mail/
> > > >
> > > > There is no reliable way to transport this prefix from the old
> > > > config to the new namespace based config as the server can
> > > > support more than one personal namespace. Therefore I do not know
> > > > what namespace should be mapped to this prefix.
> > >
> > > OK .. but then this change needs to be shepherded _really_
> > > carefully, since the effect was:
> > >
> > > 1) Upgrade KMail
> > > 2) Get 100MB of junk all of a sudden in folders
> > > 3) Lose old setting of prefix
> > > 4) Have to find setting in config dialog, guess new setting, remove
> > > additional namespaces
> > > 5) Try cleaning up folder display in IMAP and lose 100MB of data
> > >
> > >
> > > I realize this will surely improve between now and whatever next
> > > release there is, but it's best to be forewarned.
> >
> > I have to problem to improve this (hey, of course not) but the
> > question is: how? Hmm, perhaps a warning would be good when kmail is
> > launched and detects and old, non empty prefix in the config.
>
> Two things are mandatory:
> a) Upgrading must be painless. The upgrading user must not have to
> change anything in his configuration.
> b) Setting up an IMAP account needs to be trivial in the trivial case
> that the user only wants to see his folders.

And this is the goal of namespaces: that the user does not have to fiddle 
around with prefixes but the client can query the server what namespaces are 
supported for the user. And these include it's personal personal as well as 
shared and other users folders.

> Since I don't know what namespaces mean and how they are related to the
> prefix the following suggestions for solving the above problems might
> not be applicable. But anyway:
>
> ad a) Try to figure out which namespace we have to use to make it work
> as it worked before. If it's not possible to guess the correct
> namespace just from it's name then we'll have to try all namespaces and
> compare the result with the currently known folder structure. If we are
> still unsure afterwards then present the most likely configuration to
> the user. In 99.9% of all cases the user should at most have to click
> OK (ideally he shouldn't have to make anything).

Comparing the folders is ridiculous as the user could have entered everything 
in the prefix field. IMAP servers can support more than one personal 
namespace, e.g. uw imap delivers by default with "", "#mh", "#mhinbox". And 
then the user entered "Mail" in his prefix you'll get not match with one of 
the namespaces the server know. I _could_ try to overwrite any empty personal 
namespace with the old prefix but that's mere guessing.

An important note: you will probably not have any problems with cyrus or 
courier servers. The problems we're talking about come from the uw server 
which list the complete home dir of the user by default.

> ad b) A wizard. The wizard should provide a preview of the folders which
> belong to the namespaces. This way the user can still make changes
> before KMail starts to download any data except for the folder
> structure.

When should this wizard be launched? We'd have to make this before kmail 
starts a listing and this can be very early. And what should it display?
I think it's better to show a warning to the user that he should check the 
namespaces and then add a subscription dialog to the account. With this the 
user could have a preview of the folders.

> > > > Then you have an UW-imap server which supports a whole list of
> > > > namespaces and all those show up. And if you have folders that
> > > > reside under "#ftp" they will show up in the foldertree under a
> > > > folder "#ftp". If the namespace is empty it will be ignored.
> > >
> > > Yeah. I still don't know what they're _for_, though, and since the
> > > instructions I have from the IMAP admin are: "set IMAP prefix Mail
> > > in your client", I suspect that IMAP namespace support isn't
> > > widespread amongst mail clients yet. Messing around with deleting
> > > namespaces and accounts led to (5) above.
> >
> > That's not right - kmail was the only mua (AFAIK) that did not
> > support namespaces yet. The prefix was a bad workaround and you had
> > no chance to see your folders, shared folders and folders of users
> > that you are allowed to see (other users) in one account.
>
> At my university account (iPlanet Messaging Server) I could see at least
> my folders and other users' folders in one account (with empty prefix).
> So this statement doesn't seem to apply to all IMAP servers or I
> misunderstood the statement.

It depends on the server. You'll also get most of the folders with cyrus 
servers when you have an empty prefix. But will get no special folders with 
uw imap and no public folders with exchange, for example.

> I just tried to set up a new university account and got the following
> namespace structure (IIRC):
> + Personal
>   +
> + Other Users
>   + Shared Folders/User/
>
> Editting the namespaces is totally non-intuitive. Many users don't know
> that something like context menus exist so putting Delete into a
> context menu is a very bad solution. A much better solution would be a
> separate dialog with Delete and Reload buttons. The line in the config
> dialog should just show a comma separated list of the configured
> namespaces and a configure button (with the configure icon) next to it.

No, please, no comma separated list as mozilla has. This is ugly and even less 
intuitive. And then user could add any bullsh...
What about an edit and a delete button right to the listview? 
I somehow doubt that an extra dialog for an account dialog for a configure 
dialog is intuitive.

> BTW, with my university account upgrading was painless. The namespace
> support seems to work. Now we just need to polish the rough edges.

Thanks, at least someone how does not want to rip my head off ;-)


Carsten
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel

[prev in list] [next in list] [prev in thread] [next in thread]