competition

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Wed Sep 29 04:30:10 EDT 2010


Adam Tauno Williams wrote:
> On Wed, 2010-09-22 at 18:18 +0200, Jeroen van Meeuwen (Kolab Systems)
> wrote:
> >  The scenario is integration, not extension of Cyrus -which in and of
> >  itself works
> > 
> > perfecly fine and reliable for us. We're not seeking to improve Cyrus'
> > performance with *SQL db backends.
> 
> But, this assumes the data that Cyrus stores in that DB would be useful
> outside the context of the Cyrus' processes.  I've lightly played with
> the idea, and not gone any further - the data available isn't really
> very useful.
> 

Well, for one, our ActiveSync implementation wants the following information;

- List of (subscribed) IMAP folders,
- Annotations, per IMAP folder,
- Current status of the contents of such IMAP folder, such as new messages or 
deleted messages, in comparison to what the client currently holds,
- Message contents.

While connecting through the IMAP server and have Cyrus hand over the answers, 
and correlate such information on the side of the 3rd party application is 
perfectly feasible, I think it may be more efficient to correlate the 
requested information from a database directly, as opposed to attempting to 
cache the results handed over by Cyrus by each 3rd party application.

> > Imagine the following scenario; a client polls 3rd party application for
> > a list of mailboxes and the content's status very regularly -basically
> > what it's interested in knowing is whether anything changed.
> 
> Doesn't condstore solve this issue inexpensively?  [maybe I
> misunderstand condstore].  I thought it was equivalent to WebDAV/CalDAV
> ctags (which are mightily nice).
> 

I'm not sure whether the IMAP server's capabilities with regards to 
modification sequences has anything to do with this thread, but maybe I'm 
misunderstanding the IMAP CONDSTORE extension.

> > Each 3rd party app will seek to cache the
> > results somehow, for improved performance interacting with its clients
> > and as to not continuously put load on the Cyrus server.
> 
> Which is what WebDAV/CalDAV ctags are for.
> 

The WebDAV/CalDAV scenario doesn't really fly with mailboxes. For one, 
mailboxes tend to have plenty more folders and plenty more messages.

The question is not how the 3rd party app *can* get the needed information, 
the question is how many 3rd party apps can be integrated *most efficiently* 
(both in terms of performance/lower overhead, as well as architecture and 3rd 
party app's design -DYI cache for each 3rd party app?).

Kind regards,

-- 
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08


More information about the Info-cyrus mailing list