Is dimap required for calendar functions

[Till Adam]

On Wednesday 06 July 2005 22:58, Richard Bos wrote:
> Op woensdag 6 juli 2005 22:15, schreef Till Adam:
> > > Till,
> > >
> > > thanks a lot for your swift reply, that's always higly appreciated (any
> > > reason you took it from the list?).
> >
> > I didn't mean to. Probably my shitty MUA ;).
> >
> > > In other words: dimap is required for the resource folders, such as:
> > > "Kolab Server/inbox/Calendar"
> > > "Kolab Server/inbox/Journal"
> > > "Kolab Server/inbox/Tasks"
> > >
> > > But not for regular email, is that phrased correctly?  That's what I
> > > expected. Is that because korganizer needs the emails in resource
> > > folders to construct the ical files?
> >
> > Yeah, pretty much. Getting them from the imap server each time they need
> > to be dealt with is dangerous and slow, due to the asynchronous nature of
> > online imap. Which is why having them cached locally makes things much
> > more robust.
>
> Sounds pretty difficult to maintain and keep in sync (that mean praise to
> the kde-devs, that have been able get it under control!).

Well, the folders are synced up and down between client and server as part of 
the "normal" cached imap mail check, which means as far as KMail is 
concerned, they are just plain old emails, albeit ones with a special 
structure and a certain kind of attachment.

> Does it mean 
> that I as user should not touch the contents of the resource folders?

You can move these mails between folders of the same type, or delete them, 
from the resource folders like you could do with any mail. KOrganizer will 
pick up those changes and cope. Since you can't really tell what the mail 
contain, though, without looking at the mail source, that's not the best way 
to deal with them. We have KOrganizer and KAddressbook to handle them, after 
all. But you can, for example, use expiry in KMail also on resource folders, 
to move away old ones, into an archive folder, say.

> In 
> that case, how does Kontact take care that old entries are deleted and that 
> the resource folders don't grow too large in size (okay the entries are
> small, but many entries are still making a big file).  And if the user
> should not touch the resource folders why does the docu states, to make
> them visible?

You can show them to manage their ACLs, for example, which is needed to share 
them with others, or to do other normal mail things with them. See above.

Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/users/attachments/20050706/65ad7f66/attachment.sig>