[Kolab-devel] Kolab 3.0: Mime Message Storage

[Thomas Brüderli]

Christian Mollekopf wrote:
>>>> As to the X-Kolab-* headers;
>>>>
>>>> X-Kolab-Type is a duplicate of the Content-Type header to the
>>>> attachment.
>>>> I
>>>> don't really see what purpose this serves, as in addition to the
>>>> duplication, the object is also only supposed to be stored in a folder
>>>> marked as containing rfc822 encapsulated payload of a particular type.
>>> The Content-Type header is the same for all xcal/xcard headers and doesn't
>>> give us this differentiation. And doing that by the xml is painful to say
>>> the least.
>>>
>>> Since we have separate folders for the content types, it would be fairly
>>> easy to change our implementation, it could be a problem for other clients
>>> though, depending on how the code is written. If we remove the
>>> X-Kolab-Type
>>> header it is also no longer to automatically convert a single mime message
>>> (without the context of the folder), without specifying the type manually.
>>>
>>> Generally I would rather keep it, as it IMO is a useful hint for client
>>> implementors which don't have the foldertype available right away and
>>> allows to double check the type. Also I'm not that fond of relying on the
>>> folder type to "guess" the kolab object type.
>> I understand where it comes from, but I doubt whether it's needed.
>>
>> When a client without any (current) caches opens up a folder that contains
>> the same MIME content-type attachments, it does need to read all
>> attachments in order to get to the display name, summary, duration and
>> whatnot, right? What use does a X-Kolab-Type header have if all attachments
>> need to be read regardless?
> 
> It contains the same Kolab-Objects stored as MIME message. Of each message it 
> only needs to read the xml attachment. If you don't have the X-Kolab-Type 
> header you need to rely on the folder, which you're currently processing to 
> know what object to expect.
> 
> That is an unfortunate implementation detail, as ideally it would be possible 
> to just get the Content-Type of the attachment, see it is 
> "application/calendar+xml" and call readxCal(), which returns an 
> event/todo/journal. But instead we have to call readEvent, readTodo, 
> readJournal explicitly, which is what we need the exact type for.

Here's what Roundcube currently does for reading Kolab objects and how I
interpreted the current specs:

The message itself has a X-Kolab-Type header with values like
application/x-vnd.kolab.<type>

This header is either used for IMAP searches (e.g. only fetch distribution
lists from a folder of type contact or configuration objects which can be
stored in any folder) or, if iterating over all messages, we only have to
fetch the message headers to determine whether the current message is
relevant for the current task and if we have to fetch the bodystructure and
finally the XML part.

So I consider this message header as essential.
> 
>> Do we have clients that only ever want the distribution lists out of a set
>> of contacts, or is it merely a step client applications have gotten used to
>> making to separately query for all distribution lists and then separately
>> query for all (individual) contacts?

Both is possible. If caching is turned off, Roundcube issues two separate
queries in order to first fetch the distribution lists (shown as groups in
the main UI) and eventually fetch contacts when a certain folder is listed.
> 
> I'm not aware of such clients. But for contacts/dist-lists it's actually not 
> even possible to rely on the folder type, so we need the X-Kolab-Type 
> definitely.

>From the new Kolab Format draft I interpreted that the XML part of a mime
message should be annotated with a standards compilant Content-Type: with
values like application/{vcard,calendar}+xml. I'm not sure how for example
the cyrus implementation for xcard/xcal will work but I'd assume that
annotating an XML part with these Content-Type header definitely goes into
the right direction.

This is what apparently both Roundcube and Akonadi do ATM. Of course you
could consider these two headers as redundant and they obviously have to be
in sync but I see benefits for having them both.

~Thomas