[Kde-pim] Re: Review Request: Add XLIST ability to KIMAP::ListJob

[Kevin Ottens]

On Wednesday 24 November 2010 19:58:33 Torgny Nyblom wrote:
> > On 2010-11-22 16:43:29, Torgny Nyblom wrote:
> > > Come to think of it why add optional support for using the XLIST
> > > command instead of integrating this so that if the server supports
> > > XLIST always use it instead of LIST and use LIST as a fall back?
> > 
> > Gregory Schlomoff wrote:
> >     We discussed that on #akonadi, and the position from the lead
> >     developers of KIMAP was that it's a relatively low-level library,
> >     and that it should not do this kind of optimization.
> > 
> > Torgny Nyblom wrote:
> >     Guess Kevin and I disagree on that point :) Especially since there
> >     already is this sort of optimization in KIMAP (the UIDLPLUS
> >     extension).
> > 
> > Kevin Ottens wrote:
> >     There no such optimization regarding UIDPLUS. It's just that if we
> >     get extra info because of UIDPLUS, we cache it immediately. That's
> >     different from triggering automatically commands based on the
> >     supported extensions (we actually can't even detect that from the
> >     jobs).
> >     
> >     Besides in the case of XLIST, since it has no XLSUB counterpart
> >     (totally stupid IMO but we can't do anything about that) the client
> >     needs to explicitely know what it's using.
> 
> What is the reason that the client needs to know if the folder list was
> gotten using LIST or XLIST? (I haven't been able to get a good source of
> information about the XLIST command)

Well, this whole thing is loosely specified AFAIK. XLIST gives translated 
names + extra semantic flags. In such a context LSUB gives only the mailboxes 
you're subscribed to, but without said flags... but there's apparently no 
guarantee those names will be translated as well.

It *happens* that the only provider of that extension I'm aware of (namely 
gmail) translates in all cases (LIST, XLIST, LSUB) but behavior could change, 
some other server could do it differently (no RFC remember?).

That's why you need to explicitely know you're using it. Admittedly I don't 
have a large amount of trust in an extension of the protocol with no 
standardization effort behind it.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20101124/e585c858/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/