Re: SPECIAL-USE (was: Re: Cyrus CalDAV design decision)

2011-09-09 Thread Georg C. F. Greve
On Thursday 08 September 2011 10.19:53 Jeroen van Meeuwen wrote: - A Cyrus IMAP CalDAV folder containing iCalendar data could have SPECIAL-USE attributes: \Calendar \iCal [\Default] \iCal could be the defined default for a folder marked with SPECIAL-USE attribute \Calendar. - A Kolab

Re: SPECIAL-USE (was: Re: Cyrus CalDAV design decision)

2011-09-09 Thread Jeroen van Meeuwen (Kolab Systems)
Georg C. F. Greve wrote: On Thursday 08 September 2011 10.19:53 Jeroen van Meeuwen wrote: - A Cyrus IMAP CalDAV folder containing iCalendar data could have SPECIAL-USE attributes: \Calendar \iCal [\Default] \iCal could be the defined default for a folder marked with SPECIAL-USE

Re: SPECIAL-USE (was: Re: Cyrus CalDAV design decision)

2011-09-08 Thread Jeroen van Meeuwen (Kolab Systems)
Jeroen van Meeuwen (Kolab Systems) wrote: I think the RFC for SPECIAL-USE lacks the suffix '.default' we currently use in /vendor/kolab/folder-type (example value 'event.default') to indicate which folder is the default folder to save new messages that have a calendar event XML object attached

Re: Cyrus CalDAV design decision

2011-09-07 Thread Georg C. F. Greve
Hi Robert, Glad to see that you've been looking in a bit more detail. Some of the issues you've raised are definitely valid, and being addressed. On Wednesday 07 September 2011 14.45:37 Robert Mueller wrote: 1. The format never seems to have ever made it to the finished state. It's been

Re: Cyrus CalDAV design decision

2011-09-07 Thread Georg C. F. Greve
On Wednesday 07 September 2011 09.29:48 Georg C. F. Greve wrote: 10. The /vendor/kolab/folder-type annotation should be updated now that SPECIALUSE has been made an RFC I think that is a very good idea. This should likely be added to KEP 9, which is still in drafting stage, so easy to

Re: Cyrus CalDAV design decision

2011-09-07 Thread Jeroen van Meeuwen (Kolab Systems)
Georg C. F. Greve wrote: On Wednesday 07 September 2011 09.29:48 Georg C. F. Greve wrote: 10. The /vendor/kolab/folder-type annotation should be updated now that SPECIALUSE has been made an RFC I think that is a very good idea. This should likely be added to KEP 9, which is

Re: Cyrus CalDAV design decision

2011-09-07 Thread Bron Gondwana
On 09/07/2011 03:29 PM, Jeroen van Meeuwen (Kolab Systems) wrote: Georg C. F. Greve wrote: On Wednesday 07 September 2011 09.29:48 Georg C. F. Greve wrote: 10. The /vendor/kolab/folder-type annotation should be updated now that SPECIALUSE has been made an RFC I think that

SPECIAL-USE (was: Re: Cyrus CalDAV design decision)

2011-09-07 Thread Jeroen van Meeuwen (Kolab Systems)
Bron Gondwana wrote: On 09/07/2011 03:29 PM, Jeroen van Meeuwen (Kolab Systems) wrote: Georg C. F. Greve wrote: On Wednesday 07 September 2011 09.29:48 Georg C. F. Greve wrote: 10. The /vendor/kolab/folder-type annotation should be updated now that SPECIALUSE has been made an RFC

Re: Cyrus CalDAV design decision

2011-09-06 Thread Jeroen van Meeuwen (Kolab Systems)
Dave McMurtrie wrote: Good day, Ken, Bron and I have had various disjointed conversations about where CalDAV data should be stored. We're getting to a point where we really need to finalize that design decision, so I'm soliciting feedback here. The current Cyrus CalDAV code stores DAV

Re: Cyrus CalDAV design decision

2011-09-06 Thread Jeroen van Meeuwen (Kolab Systems)
Ken Murchison wrote: Bron Gondwana wrote: On Tue, Aug 23, 2011 at 02:44:46PM -0400, Dave McMurtrie wrote: 3) Store DAV resources in a separate hierarchy like the DELETED hierarchy. I think Ken and I initially liked this idea, but the more we talk about it, the more it seems like this is

Re: Cyrus CalDAV design decision

2011-09-06 Thread Robert Mueller
(Resending to include cyrus-devel) At the moment, the storage format in use is iCalendar, being stored as RFC5322 messages. That sounds very much like what Kolab did in version 1. After trying to make this interoperate for several years it was given up in favor of the Kolab XML format

Cyrus CalDAV design decision

2011-08-23 Thread Dave McMurtrie
Good day, Ken, Bron and I have had various disjointed conversations about where CalDAV data should be stored. We're getting to a point where we really need to finalize that design decision, so I'm soliciting feedback here. The current Cyrus CalDAV code stores DAV resources as subfolders of

Re: Cyrus CalDAV design decision

2011-08-23 Thread Dave McMurtrie
On 08/23/2011 02:54 PM, Georg C. F. Greve wrote: On Tuesday 23 August 2011 14.44:46 Dave McMurtrie wrote: At a high level, here are the different ideas we've discussed: There is actually one additional possibility that has been suggested and discussed to some extent which is missing from that

Re: Cyrus CalDAV design decision

2011-08-23 Thread Dan White
On 23/08/11 14:44 -0400, Dave McMurtrie wrote: Good day, Ken, Bron and I have had various disjointed conversations about where CalDAV data should be stored. We're getting to a point where we really need to finalize that design decision, so I'm soliciting feedback here. The current Cyrus

Re: Cyrus CalDAV design decision

2011-08-23 Thread Georg C. F. Greve
On Tuesday 23 August 2011 15.23:43 Dave McMurtrie wrote: At the moment, the storage format in use is iCalendar, being stored as RFC5322 messages. That sounds very much like what Kolab did in version 1. After trying to make this interoperate for several years it was given up in favor of the

Re: Cyrus CalDAV design decision

2011-08-23 Thread Dave McMurtrie
From my phone, so please excuse any brevity and the top-post. I understand your passion for the storage format, but the reason I wanted to keep it as a separate thread was because the amount of code that needs to be modified to alter the existing storage format is relatively trivial (entirely

Re: Cyrus CalDAV design decision

2011-08-23 Thread Georg C. F. Greve
Hi Dave, On Tuesday 23 August 2011 18.26:42 Dave McMurtrie wrote: I understand your passion for the storage format, but the reason I wanted to keep it as a separate thread was because the amount of code that needs to be modified to alter the existing storage format is relatively trivial