competition

[Adam Tauno Williams]

On Wed, 2010-09-22 at 18:18 +0200, Jeroen van Meeuwen (Kolab Systems)
wrote:
> >> Kolab Systems is thinking of such SQL databases for integration purposes,
> > > where the performance penalty now lies within having to use the IMAP
> > > protocol to gain access to the underlying metadata (seen status, message
> > > indexes) in distributed groupware environments where Cyrus itself is not
> > > the only component that needs access to such information (but would still
> > > remain authoritative, of course, and would be the only component with 
> >write
> > > access to most tables).
> >> While not necessarily the best approach, it seems worth exploring.
> >What makes you think the query parsing and other overheads of SQL will 
> >be faster than IMAP?
> >I'd be interested in any numbers that you might have to support the effort.
>  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.

> 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).

> 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.