Cyrus process model...

[Rob Siemborski]

On Wed, 26 Feb 2003, Rob Mueller wrote:

> [ Continued from an off mailing list conversation about killing Cyrus lmtpd
> processes when they go haywire, and cyrus process accounting ]

Actually, cyrus-devel would have probably been an even better place to put
this (and I'm cross-posting there).

> Would the cyrus team think it worthwhile to consider refactoring to use the
> new Apache 2 APR modules? I know off hand that it would be a lot of work,
> but it could be a gradual re-factoring process, and the idea of actually
> reusing code between projects would be *really* nice.

I'm definitely in agreement about refactoring (indeed, your original Sieve
issue just went away in 2.2, since we gutted most of the sieve framework
to use compiled bytecode instead).

I am nervous every time someone suggests adding a dependency, however.  As
it is, Cyrus has a larger-than-average [potential] number of dependencies:

Berkeley DB
Kerberos / GSSAPI
AFS
(in 2.2) OpenLDAP
Perl
OpenSSL
Cyrus SASL
 which in turn can potentially depend on [in addition to some items
  above]:
 GDBM/NDBM
 MySQL

Probably more which escape me at the moment.

The fact is, given the number of problems people already have getting the
dependencies to play nicely together, I am hesitant to add another.
Additionally, its hard enough to keep up with the changes between every
version of Berkeley DB (which are basically limited to 1 file in IMAPd,
and 2-3 in SASL), I can't imagine what it would be like if we had to do
that for most of (more than?) the functionality currently provided by
libcyrus.

As for your comments about the age of Cyrus's code, yes, that's true,
there are portions that show their age more than others (non-ANSI
prototypes, use of strcpy, strcat, etc).  However, we clean up the
non-ANSI stuff as we see it, and Security Appraisers and Bynari are
currently helping us clean up the string manipulation routines to be more
modern (along with other potential security issues).

As far as memory allocation, libcyrus has memory pool routines, and we use
them where there is an efficiency benefit to do so (maybe we could do
better, I don't know).  It is not entirely clear to me that we should use
them in a global way, especially on long-running connections (apache can
use them globally, since HTTP connections are typically short-lived).

In any case, we're always open to listening to new design ideas (that
doesn't mean we will automatically do whatever is suggested of course ;).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper