Re: Listing IMAP folders

[Philip Van Hoof <spam pvanhoof be>]

Hi Lucas,

The best solution would be to let Tinymail upon discovery of a folder
that has children (\HasChildren or something in IMAP, if I remember it
correctly) when doing a non-recursive LIST, do a pipelined LIST request
for the subfolder (and repeat this recursively for all folders that must
be visible in the UI).

Unfortunately this means having a local folder-info store that copes
with this in a fairly flexible manner. That is ... whenever you'd use
the E-mail client offline, the user wants to have at least the folders
that were available when he/she was online and that he/she has used
before.

At the same time when the user decides to go online, and a folder is
visible that either now suddenly has gotten subfolders or that had
subfolders already, is visible, then Tinymail would have to auto start
requesting LISTs in the same pipelined manner, storing retrieved info,
etc

I think you probably already smell the point that I'm trying to make,
no? :-)

The point is: Camel can't do pipelining at all. Camel's folder-summary
is very inflexible (especially for this kind of dynamic behaviour of the
flow of code) and camel's LIST and LSUB code is really too simplistic
for this.


I know that I wrote: camel, camel, camel it's all camel's fault. And
from a Tinymail application developer's point of view he/she doesn't
want to care about Camel's limitations. (and I agree with that)

Truth is, that for this kind of folder-scheme to work, we'd have to
redesign and therefore also reimplement a Camel. While doing that, we'd
need to have this use-case in mind.

If there would be a team of people (and I'm indeed looking at for
example the Igalians and at companies like Nokia for funding) ready to
work with me on this ...

... then I'd go for a new IMAP client design/library/code.

I would have a good idea for a design for this, and I have a very good
picture of what the use-cases are and what is needed.

Right now, however, I'm occupied by another project (being tracker). 


ps. It's funny (for certain values of 'funny') that almost all E-mail
client developers after they finished a modest E-mail client like
Evolution (it's nothing much if you take into account what IMAP offers
you - Evolution uses almost nothing of IMAP's capabilities -), burn
out. 

Most of these developers have really good ideas .. but no more energy
left. I'm still hoping to collect some of them into a team that will
just ignore the fact that they no longer have fuel, and just go for it.




On Sat, 2008-07-12 at 13:41 +0100, Lucas Maneos wrote:
> Hi all,
> 
> following up on the discussion in Modest bug #2537
> (<https://bugs.maemo.org/show_bug.cgi?id=2537>) at Philip's request
> (and apologies for the delay).  This is more from a user (than
> developer) point of view though.
> 
> To summarise, the current tinymail behaviour AIUI from observation and
> reading libtinymail-camel/camel-lite/camel/providers/imap/camel-imap-store.c
> is:
> 
> a) for the personal namespace, unconditionally LIST all folders
>    recursively (ie, using a "*" wildcard)
> 
> b) for the shared and other namespaces, LSUB folders recursively
>    unless the namespace prefix is empty ("")
> 
> c) for shared / other namespaces with empty prefix, LSUB top-level
>    folders only ("%" wildcard)
> 
> The rationale/assumption is that the personal namespace should contain
> only a few folders while shared namespaces may contain large folder
> hierarchies (for example proxying Usenet groups).  Both of these are
> wrong for me :-(
> 
> The c) case is causing problems with Cyrus imapd, which advertises the
> shared namespace prefix as "".  The result is that only top-level
> shared folders (which typically only contain subfolders) are listed,
> but nothing underneath.
> 
> The obvious work-around that comes to mind is to extend c) to also
> LSUB any shared folders found.  Actually, the "best practices" wiki
> (<http://www.imapwiki.org/ClientImplementation/MailboxList>)
> recommends to do that, but only upon explicit user action and only one
> level at a time.  This would be very nice indeed, and solve the
> problem as well as provide adequate protection against unintentionally
> listing huge hierarchies.
> 
> Now, the flip side of this is my personal IMAP account, where
> the a) case above is also causing problems.  Background: as a result of
> using mutt for the past decade or so (and elm before that) and the
> benefits of readline I have accumulated:
> 
> 	$ find Maildir/ -type d -name cur| wc -l
> 	503
> 	$ find Maildir/ -type f| wc -l
> 	173060
> 
> (all served by dovecot under a "" personal namespace).  The largest
> folder contains ~64K messages.  On the other hand, INBOX is usually
> kept small and the subscriptions list contains only a few folders.
> Obviously I don't expect tinymail to handle that volume of email
> efficiently (or at all) and indeed modest currently doesn't.  Part of
> the problem is the large folders, but even when temporarily moving
> those out of the Maildir tree it still takes about 20 minutes to go
> through the whole list (otherwise it doesn't complete even when I left
> it spinning at ~100% CPU overnight).
> 
> I realise that this is not a very common scenario (some might say I'm
> "asking for it"), but then again neither is exporting the entire Usenet
> via IMAP.  It would be really great if tinymail could support the option
> (it doesn't have to be the default, as long as it's there) of listing
> only subscribed personal folders.
> 
> Thanks,
> Lucas
> 
> _______________________________________________
> tinymail-devel-list mailing list
> tinymail-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/tinymail-devel-list
> 
-- 
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