[Kolab-devel] Kolab client developers: PLEASE ADHERE TO THE DEFAULT FOLDER SPEC (was: Re: autocreate functionalities in cyrus)

Gunnar Wrobel wrobel at kolabsys.com
Thu Oct 14 08:44:18 CEST 2010

Zitat von Alain Abbas <alain.abbas at libertech.fr>:

> Bernhard Reiter a écrit :
>> Am Sonntag, 19. September 2010 21:06:25 schrieb Alain Abbas:
>>> Is Autocreate Patch is in Kola- cyrus ?
>>> and if yes how to automaticly create Calendars and contacts folders
>> As far as I remember, when designing the format, our idea way back then was
>> that the clients are creating the default groupware folders and they
>> should create them as necessary and in their local language.
>> So if default folders are missing that your client (e.g. the z-push sync
>> client) needs, it could just create them.
>> Bernhard
> Yes but the problem is that we haven t normalization about the names and
> for exemple if you connect first time
> with horde Horde create "Agenda" (in my language) and if you connect the
> first time with Outlook (bynari or others)
> it creates "Calendrier" and some clients doesn t put annotations or read
> it to retrieve the default calendar (for example)

This is a serious bug of the client then!

I quote from the format docs  

"The actual names of the folder as stored on the IMAP folder don't  
matter. E.g. it does not matter if the default calendar is called  
Calendar or Kalendar as long as exactly one default calendar folder  
does exist as a direct subfolder of the INBOX folder."

And I consider that to be a very sane approach. When the user connects  
to the Kolab account with his favorite Kolab client for the very first  
time this client has the chance of creating the default folders with  
exactly the names that users of this client are used to. All other  
clients used subsequently *should* have no problems dealing with these  
folders. It also allows users to rename the folders to anything they  

> The user have sometime 2 calendars or 3 created by one or 2 or 3
> applications
> i think it would be good to have a name convention for all applications.

I don't think this would solve the problem. Look at the current  
situation: There is a clear convention defined that would work if all  
clients adhere to that convention. Why should that change in any way  
if the convention is to use the same name? I'm certain there'd be  
clients not adhering to this either so the resulting situation would  
be the same.

So the only solution is to file an urgent bug with the  
vendor/developers of that specific client.

As Kolab support is improving on the client side and people rely more  
and more on mobile clients we can really expect users to use different  
Kolab clients nowadays. So I consider this indeed critical. Which is  
why I changed the subject of this mail.

I really want to stress that *not adhering* to the spec means that the  
new users of the defect client will have an unpleasant first user  
experience in case they used another client before. "Where on earth is  
my data?" is maybe not the first reaction you want to provoke in case  
you want to convince users that your client is the better one ;)



> Alain
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

Gunnar Wrobel
Developer, Kolab Systems AG

e: wrobel at kolabsys.com
t: +49 700 6245 0000
w: http://www.kolabsys.com

pgp: 9703 43BE

This message was sent using IMP, the Internet Messaging Program.

More information about the devel mailing list