[Kolab-devel] caldav backend to calender plugin

Daniel Morlock daniel.morlock at gmail.com
Mon Mar 24 14:01:44 CET 2014


Hi Thomas,

thanks a lot for your time and effort!
Please see the answers attached inline:

On 2014-03-24 11:40, Thomas Brüderli wrote:
> Hello Daniel
> 
> I finally found some time to have a look at your work for the Kolab
> calendar plugin to add CalDAV and iCal capabilities. First of all, many
> thanks for your work and for sharing it with us!
> 
> Although I had some troubles getting it to work initially, the
> multi-driver setup looks quite nice. So here are some remarks and
> questions I have after the first quick look:
> 
> * The idea of extending the database_driver for synchronizing CalDAV 
> and
> iCal sources seems quite obvious. Here I'd suggest two things:
> 
> 1. Use dedicated tables for calendars and events and override
> $db_calendars and $db_events properties in the caldav_driver class.
> 
> 2. Store the additional properties (url, etag, etc.) right in these
> tables to avoid additional queries.

Point. But I think this are cosmetics in the database design where 
performance is not necessarily needed.

> 
> * Question: what's the reason why driver names have the appendix 
> "_driver"?
> 
> * You use an additional library and an extra config option to encrypt
> the caldav/ical passwords. Why not using the already existing methods
> from Roundcube core (rcube::encrypt and rcube::decrypt)? My PHP doesn't
> have the Mycrpt extension and thus failed with fatal errors.
> 
> * For CalDAV synchronizing, I had to change REPORT <c:calendar-query>
> with a PROPFIND request because SabreDAV driven CalDAV servers don't
> support queries with no query criteria.
> 

Indeed there might be some issues with different servers. Would you mind 
to send me a patch or similar so I can add it to the caldav branch?

> 
> Some minor problems I found so far:
> 
> * Attachments to events don't get synchronized to the CalDAV server

Yep, this feature is still missing.

> 
> * Moving an event from one driver to another fails
> 
> * Input fields for calendar URLs are a bit too small
> 
> * Stored passwords should not be populated the calendar edit form
> 
> * Auto-discovery kicks in even if I supply a full URL to a calendar
> resource.
> 
> 
> But finally, your changes integrate nicely and add good value to the
> calendar codebase. KUDOS! We're certainly interested in adopting the
> multi-driver changes and the iCal driver at first. For CalDAV I'd be
> interested in seeing the implementation of Chris Moules for comparison.

Sounds legit. I'm also interested in Chris Moules implementation. Are 
there any sources available?
Please keep me informed about your experience with Chris Moules 
implementation!

> 
> I'm not yet sure about the integration path for your commits into our
> upstream repository. The new multi-driver changes are quite significant
> and have the potential to break the calendar in a major way. Currently
> some refactoring of the entire iTip handling is going on in git master.
> Once that's done, we'll likely start with branching off git master and
> then adding your changes to it. I'll keep the mailing list updated with
> the progress on this.

Thanks a lot! Please don't hesitate to come back to me if you have any 
questions or if I can help you further!

> 
> So again, many thanks for your work and stay tuned.

I will stay tuned =)

> 
> Kind regards,
> Thomas

Kind regards,
Daniel.

> 
> 
> Daniel Morlock wrote:
>> 2. Use the latest development sources:
>> 
>> $ git clone https://gitlab.awesome-it.de/kolab/roundcube-plugins.git
>> $ cd roundcube-plugins
>> $ git checkout feature_caldav
>> 
>> This can contain yet untested code and you might experience things 
>> like
>> the parentheses error. Should be rare, but it could happen.
> 
> _______________________________________________
> devel mailing list
> devel at lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/devel


More information about the devel mailing list