Luca Ceresoli wrote:
Hi Cyrus and Buildroot developers,
I'm working to add cyrus-sasl and cyrus-imapd (http://www.cyrusimap.org/)
to buildroot (http://www.buildroot.net/) for use on embedded systems.
On my road I hit various problems with the cross-build process:
configuration, compilation and
Hello,
- cyrus-imapd: static binaries are huge, cannot build them shared;
- cyrus-imapd: choose binaries to (build and) install;
Not solved. The good thing is that Дилян Палаузов Dilyan Palauzov
volounteered to update the cyrus-imapd buildsystem
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
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 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
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
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
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
