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 a
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 list:
4) Use an existing IMAP based groupw
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
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 the hardest to
> implement and we can't rememb
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 Ca
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 Ko
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 the hardest to
implement and
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
c
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
> (e
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
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 li
(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 XM
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 be
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
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,
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
> >
> >
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 bee
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 attac
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 Kol
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 SPEC
20 matches
Mail list logo
