On 10/09/2015 22:43, Timo Sirainen wrote:

I've been once in a while over the years thinking about implementing CalDAV (and CardDAV) to Dovecot. It might be time to start that soon. Does anyone have any suggestions? So far my main goals would be: a simple method for handling calender permissions. ie, private calenders, public calenders, and limited access calenders radical is easy to install, but working out permissions for editing/viewing I found less than simple. having permissions, or at least login tied with dovecot reduces password admin.

• scalable, of course
• configurable storage (object storage, regular fs, maybe some key-value dbs, maybe storing as emails) It may be able to be implemented in a text file or sql table, but I'm not sure how the mua's handle adding entries/calenders/changing permissions etc. If it would work for thunderbird and ms outlook, it would cover a large section of the local userbase that may use it, and working with squirrelmail and roundcube would cover most of the webmail based users
• efficient indexes (potentially using key-value dbs? or maybe just local files. not sure yet what kind of indexing is needed)
• have it work with dsync (= replication & migration)

Some things I wonder about:

• Maybe there is already some code out there that could be used to implement it faster?
• Maybe even use something else besides C to implement it.. Then again that makes integration to Dovecot more difficult.
• Is anybody interested in helping to develop this? :) I think I still have too much other work that I won't spend a lot of time coding it..

One thing that makes this easier is that Open-Xchange has already implemented a CalDAV server, so they can help to avoid the biggest design mistakes. (There are a couple of reasons why they'd want to replace that.)

On Fri, 11 Sep 2015 00:43:16 +0300 Timo Sirainen <tss@iki.fi> wrote:

I've been once in a while over the years thinking about implementing CalDAV (and CardDAV) to Dovecot. It might be time to start that soon. Does anyone have any suggestions? So far my main goals would be:

• scalable, of course
• configurable storage (object storage, regular fs, maybe some key-value dbs, maybe storing as emails)
• efficient indexes (potentially using key-value dbs? or maybe just local files. not sure yet what kind of indexing is needed)
• have it work with dsync (= replication & migration)

Have you heard about SOGo yet?

http://www.sogo.nu/

It is an entire groupware server but its focus lies on scalability implemented through open standards. For an overview check

http://www.sogo.nu/english/about/technology.html

I haven't used it myself yet but I am planning to do so.

--

Niklaas

Am 10.09.2015 um 23:43 schrieb Timo Sirainen:

I've been once in a while over the years thinking about implementing CalDAV (and CardDAV) to Dovecot. It might be time to start that soon. Does anyone have any suggestions? So far my main goals would be:

• scalable, of course
• configurable storage (object storage, regular fs, maybe some key-value dbs, maybe storing as emails)
• efficient indexes (potentially using key-value dbs? or maybe just local files. not sure yet what kind of indexing is needed)
• have it work with dsync (= replication & migration)

Some things I wonder about:

• Maybe there is already some code out there that could be used to implement it faster?
• Maybe even use something else besides C to implement it.. Then again that makes integration to Dovecot more difficult.
• Is anybody interested in helping to develop this? :) I think I still have too much other work that I won't spend a lot of time coding it..

One thing that makes this easier is that Open-Xchange has already implemented a CalDAV server, so they can help to avoid the biggest design mistakes. (There are a couple of reasons why they'd want to replace that.)

Hi Timo, caldav / carddav in dovecot will be an ultimate nice feature.

I remember Kolab with imap file storage backend, storing vcard, ics in imap folders. ( which should be hidden )

There was a thunderbird plugin for this, but i had no good performance. Advantage of this solution might be the exist imap acl system can be used for all kind of addressbook , kalendar sharing. Perhaps public addressbooks and calendars are possible too this way ( and at last anonymous read only ones ).

All other servers i know use some db backend. I guess you will have hard times with clients, cause there are all kind of known bugs.

Specially serial appointment with/and different timezones over summertime and wintertime changes seems difficult to code. Best way all in UTC and let the client convert it in its local timezone.

Also there are two ways of invitations notices via mail , let the client send it, or the server has to do it ( or perhaps combinate ).

So resources calenders are needed too ,for auto booking calenders you need some kind of scripting. For the first releases mark as higly beta , its very bad for user if they trust in calenders which might have bugs.

the new thunderbird carddav addressbook seems to stuck since years

https://github.com/mikeconley/thunderbird-ensemble

Of course i am willing to test your code and report.

Best Regards MfG Robert Schetterer

-- [*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

On Fri, 11 Sep 2015 00:43:16 +0300 Timo Sirainen <tss@iki.fi> wrote:

I've been once in a while over the years thinking about implementing CalDAV (and CardDAV) to Dovecot. It might be time to start that soon. Does anyone have any suggestions?

Perhaps support for LDAP as a backend for retrieving contact information (CardDAV) and/or a way to sync the contacts between Dovecot and LDAP in some sane way. This could end-up being more trouble than worth, though.

Best regards

-- Branko Majic Jabber: branko@majic.rs Please use only Free formats when sending attachments to me.

Бранко Мајић Џабер: branko@majic.rs Молим вас да додатке шаљете искључиво у слободним форматима.