[Kolab-devel] Kolab Support for the Toltec Connector

[Joon Radley]

Hi Bo,

> > > > 2) What is the
> > > > format of the hidden synchronization message in the folders?
> 
> There are no hidden sync messages in the folders.
> 
> > > This message is sofar not finally defined. I will make a proposal
> > > later. Basically the KDE Kolab Client currently does not support
> > > multiple folders of the same type e.g. multiple calendars.

To conclude, the client cannot determine the type of a folder until the users maps the folder. So when accessing the message store for the first time the users needs to map the type of the folder. Every time the a new client is installed/reinstalled this mapping must be done, even for a different client like horde. This includes the translation of the names of folders as well.

So information regarding the content and the name of a folder is only stored on the client side.

> ... but I agree it would be nice to have such a message, so we never have 
> the problem of seeing the long list of iCals in the mails.

Yes, it would be nice :-)
 
> > > > 3) What is the
> > > > format of the "groupware" messages?
> > >
> > > What do you mean?
> >
> > IMAP stores the messages in RFC822 format. Now if you have a mail with
> > multiple MIME parts of text/plain and text/x-vcard, is this a groupware
> > contact message or a normal email message where the sender has attached
> > his VCARD.
> >
> > Now from what I can see from your document and the answer of question 1
> > you infer the type of the message based on the mailbox that it is
> > stored in. This can be a bit ambiguous.
> >
> > Maybe this can be resolved by the following:
> >
> > 1) The following additional headers in the RFC822 message:
> >    X-KOLAB-TYPE: Appointment/Contact/Note/Journal/Task
> >    X-KOLAB-TYPE-VERSION: 1
> >
> >   With this the RFC822 message defines the content of the groupware
> > object. The version for each type will help later, when changes to the
> > formats take place.
> 
> Can you make Outlook do that easily? I doubt it. And the fact that it can 
> be done is not enough - think of a corporation with 10000 users that all 
> have to set these options (if it can be done). Support hell.

With a well defined object a client can choice how to display this. Yes, Outlook cannot display different object in the same folder (except the deleted items), but it will not try to force a object to be viewed incorrectly.

> No special headers.

 
> > 2) The message is made up of two MIME parts:
> >   text/plain: A text summary of the groupware object.
> >   text/*: The actual object like text/calendar or text/v-card
> >
> > What do you think?
> >
> > Also in the document NOTES and TASKS have the MIME type text/plain,
> > maybe it can be changed to text/x-note and text/x-task. Journals are
> > undefined in the document. (RFC2445 VJOURNAL)
> 

> KMail and Outlook will look at the contents of a mail like that, and find 
> the iCal in there. If it's in the text, it uses that. If it's in a mime 
> attachment and has type text/calendar, it finds that.

This will work fine where a MIME type is defined, but what about notes and tasks?

> > > > 4) The directory structure used by the other Kolab clients?
> > >
> > > What do you mean?
> >
> > How does Kolab clients manage subdirectories on the server side?
> 
> We specify in the client, which folder should be the parent of the 
> groupware folders. In that parent, we place folders named "Calendar", 
> "Contacts", "Notes", and "Tasks". If the users want to, they can get the 
> localized names Outlook uses, but I really hate that, because the MS 
> morons translated the folder names on disk instead of just in the GUI.

As long as I have data persistence in folder names you can call me a moron ;-)

WOW!!! And me without my fire proof underwear.

I only wrote the mail to obtain information on how other kolab clients interact with the backend. Naturally I will ask questions and float some ideas for some open discussion. 

WOW!!! a Moron, really? :-)

Regards

Joon