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

List:       kde-pim
Subject:    Re: [Kde-pim] IMAP namespaces
From:       Ingo =?utf-8?q?Kl=C3=B6cker?= <kloecker () kde ! org>
Date:       2005-05-15 15:15:30
Message-ID: 200505151715.41256 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 15 May 2005 15:33, Carsten Burghardt wrote:
> 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.

So, usually (when using a sane IMAP server) the user doesn't have to 
change anything with regard to the namespaces?

> > 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.

As I said, I don't know how namespaces are used in IMAP so my 
suggestions might have been stupid. Are the "#mh", etc. namespaces 
useful at all? Should namespaces which being with a '#' probably be 
disabled by default? Doesn't the prefix correspond to some folder 
within the folder structure below the different namespaces or how does 
the prefix work? Sorry, for asking stupid questions.

I don't understand the last sentence. I thought the namespaces were, 
exclusively, defined by the server. But it's possible to change 
namespaces? Or only an empty personal namespace?

> 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.

Is it possible to hack in some code which tries to deal with this?

> > 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.

The wizard is for creating new accounts. It should come up instead of 
the configuration dialog and guide the user through the configuration 
(with the possibility to skip it and go to the configuration dialog if 
desired). Of course, this is a generic wish and not really related to 
the namespace stuff.

> > 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...

I forgot to mention that the comma separated list shouldn't be editable. 
For editting the user has to open the dialog.

> 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.

The account dialog has already too many settings for my taste. And what 
you propose will surely violate all usability standards.

Regards,
Ingo

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

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