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
(http://asg.andrew.cmu.edu/archive/message.php?m
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
11 matches
Mail list logo
