Re: [Evolution-hackers] Support for LIST-EXTENDED's SUBSCRIBED parameter

[Philip Van Hoof <spam pvanhoof be>]

I further changed Camel-lite in such a way that only the following
protocol conversation takes place:

if CAPABILITIES contains NAMESPACE
  -> NAMESPACE
  <- NAMESPACE (("namespace that matters" "dir_sep_char") ... )
  # Camel ignores the other namespaces (this is bad!)
  item = "namespace that matters" + dir_sep_char + "*" or "%"
else
  namespace = false
  item = "*"
endif

Note that usually "namespace that matters" is simply "INBOX". Note that
Camel ignores all not-first namespaces (and that supporting all
namespaces implies a format change of the CamelStoreSummary's caching).

Then this is done to know the subscription state of INBOX (and counts as
a roundtrip, I'm still figuring out how I can avoid this one as I think
it's unnecessary):

(now, this only happens if namespace != "")

if capabilities contains LIST-EXTENDED
  -> LIST (SUBSCRIBED) "" INBOX
  <- LIST (\Subscribed) INBOX ...
else
  ->  LIST "" INBOX
  <- LIST INBOX ...
  ->  LSUB "" INBOX
  <- LSUB INBOX ...
endif

This is getting the list of folders. Either item is "namespace.*' or
it's "*". Note that requesting "*" is a very bad idea for very large
folder lists (it's recursive, not all IMAP servers will like you for
doing this, and it'll be a lot slower than requesting "%" in stead).

In case you don't request a recursive list, Camel puts "%" in stead of
"*", but note that most of Evolution's code requests a recursive one (so
it'll at least once occur that a recursive is requested, and therefore
it'll request it as "*" anyway, or at least that's what I saw happening
when analysing the traffic).

Better would indeed be to request a new list each time you click-open a
tree node, and request "%" in stead. This might not be practical for the
UI developer, though.

Here the LIST-EXTENDED changes kick into action.

if capabilities contains LIST-EXTENDED
  -> LIST (SUBSCRIBED) "" item
  <- LIST (\NonExistent \Subscribed) ...
  <- LIST (\Subscribed) ...
  <- ...
else
  -> LIST "" item
  <- LIST ...
  -> LSUB "" item
  <- LSUB ...
endif

Now. What Evolution does (it doesn't support the LIST-EXTENDED case) is
merge the LIST and LSUB together while marking items in LSUB as
CAMEL_FOLDER_SUBSCRIBED. Marking them is fine, of course, but merging
them together is utterly wrong. 

Courier is one of the IMAP server that don't do housekeeping of LSUB
when you for example delete a folder yet don't unsubscribed it first.
The net result is that with Evolution you get folder-nodes that don't
exist at the server.

For the user this means that when he clicks on that folder-node, that he
gets an error about the folder not existing.

Of course in Courier you can have subfolders of folders that don't
exist. Oh the joys of IMAP :) (and the joys of server people disagreeing
on the interpretation of the standard).

As how I see it should the IMAP server give in its LIST response a
\NonExistant and/or \NoSelect flag for such folders. But should not omit
them in LIST. But merging LSUB and LIST together is even more wrong. At
least in my opinion (you end up showing folders to the user that simply
don't exist on the server).

Note: A greyish tree node that presents a parent for child-folders when
it ain't selectable ... would be a more correct UI presentation of such
a \NoSelect parent folder (or, placeholder in the folder tree).

Note. An example is the [GMail] folder of Google IMAP. Google's IMAP
server is one of the first times that I saw \NoSelect being actively
used by an IMAP server in a default-ish way.

Evolution will soon get a lot of GMail IMAP users ...

Sounds like something to correctly handle from now on.




On Wed, 2007-12-19 at 21:32 +0100, Philip Van Hoof wrote:
> The net result of this patch is less round trips when connecting with an
> IMAP server that has support for LIST-EXTENDED.
> 
> http://tinymail.org/trac/tinymail/changeset/3155
> 
> Note that Evolution merges LIST and LSUB together. This is wrong
> behaviour. An item not in LIST yet in LSUB simply doesn't exist.
> 
> 
-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be