[imap5] Considerations from Akonadi/Kontact/Kmail implementers

[Jeroen van Meeuwen <[e-mail]>]

Hello there,

Having attended the KDE PIM development sprint in Osnabrueck last weekend,
I wanted to start summarizing the feedback I've gotten so far, from the 
developers of the KDE PIM stack, responsible for Kontact (Kmail), Akonadi[1] 
and Nepomuk. This is not the complete feedback, however, and I hope to be able 
to find ways to have the actual implementors render their own feedback on this 
list.

I'd like to view this feedback in the realm of personal information 
management, as some things may be workarounds for deficiencies in IMAP4, and 
other things may just simply not apply (to IMAP4, or even to IMAP5).

Also, let me state this is only some initial feedback; Akonadi implements a 
interface that takes a subset of IMAP4 commands, enhanced to serve its use-
cases. I think that's very valuable feedback for the IMAP5 discussion, as it 
clearly points out what this particular client implementer needs, and what 
they don't (i.e. what they could do away with in IMAP5, perhaps).

First of all, please allow me to illustrate where Akonadi fits in, in relation 
to Kmail / Kontact.

Akonadi is used as the universal storage layer for information aggregated 
through/from different resources - one of them is an IMAP resource. When the 
client (Kmail for email) wants to speak IMAP, it speaks a derivative "Almost 
IMAP" protocol to Akonadi - Akonadi spawns an "IMAP Agent" to get the actual 
data out of IMAP - which of course speaks IMAP "fluently".

Akonadi is also the storage for the other applications wrapped up in Kontact - 
calendars, contacts, notes, tasks, journals, etc. Obviously, traditionally, an 
IMAP4 client has had to find another place to store such data.

So, in the realm of things they made disappear or want, or that Kolab would 
like to offer for consideration;

- No more selecting any mailboxes in order to allow operations against it.

I suppose this mandates all operations use full or relative URIs, such as:

  C: <tag> FETCH "/Folder/Sub-Folder/<uid>"

and:

  C: <tab> APPEND "/Folder/Sub-Folder/" <message>

There's been words about notification systems, possibly using a global 
UIDVALIDITY / MODSEQ, that I think are a step in the right direction to do 
away with mailbox-by-mailbox selection to get one's hands on any changes.

- Simplification of getting folder properties, including size, 
MODSEQ/UIDVALIDITY/UIDNEXT and other such metadata on the state, quota(root), 
ACLs (MYRIGHTS/GETACL simplification), METADATA, etc.

- "Fast" synchronization (of selected state changes only) - it's been 
suggested sometimes a client is only interested in NEW messages, or NEW before 
any other action(s)/change(s) are communicated (i.e. other actions such as 
flag changes, deletions, etc.). Please note I think QRESYNC is already 
supported, but on a mailbox-per-mailbox basis, it's still "slow" and doesn't 
allow one to get only to NEW messages, for example.

- Rather specifically pointing in one direction, but the work that's been done 
by Opera on conversations is very interesting to the Kontact client 
developers.

- The concept of "local" subscriptions could be translated into a mechanism 
that allows a client to subscribe to notifications on changes on explicit 
(sets of) folders.

Right now, there seems to be a variety of selectors;

  a) server-side subscriptions, which is only ever one list,
  b) namespaces (INBOX/, user/, shared/, if you will),
  c) "local" subscriptions - where the client is configured to ignore certain 
folders when pulling down the data. One can imagine one's Archive/* folders 
need to be available in a web mailer, but not on a mobile device, for example.

- Access to different data than only traditional email, specifically items 
that relate to groupware, such as (but not limited to) calendaring and 
contacts. This is currently being performed with xcal/xcard attachments to 
RFC822 messages. I think Calendaring and Contacts are first on the list of 
things a "IMAP user" would want to see included.

- The requirements for client-side (full-text) search are 
currently implemented using Nepomuk/Strigli, the interface/indexer, after 
having obtained the original information from these messages (and decoding any 
base64 or other encoding that is done in order to be able to store as 
attachments).

- In light of projects, tasks, journal and notes, it is thought that 
conversations (again) can be used / abused to build (on the client side) the 
desired relationship trees between the various components within a project 
(i.e. tasks, events, contacts, journal and notes, thus building "projects").

- It's also been considered that a good client protocol library might be 
helpful. I'm not sure what this would look like exactly, but I suppose such 
library would take away a little of the protocol parameter(s) syntax 
complexity. Bonus points, of course, if bindings for various languages could 
be generated on top of such library.

Kind regards,

Jeroen van Meeuwen

[1] http://community.kde.org/KDE_PIM/Akonadi

--
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: [phone]
m: [phone]
w: http://www.kolabsys.com

pgp: 9342 BF08