[Dovecot] Documentation

[Jon Roma]

Curtis Maloney <cmaloney at cardgate.net> wrote:

> Jon Roma wrote:

Curtis Maloney <cmaloney at cardgate.net> wrote:

>>>> And then there's the whole joy of building Cyrus SASL that goes with
>>>> building the IMSP/ACAP server. Yuck.

>>> Why bother using Cyrus SASL when Dovecot has its own SASL
>>> implementation?

>> This has nothing to do with using SASL to authenticate to Dovecot.

It looks like you assumed that I was building Cyrus SASL in place of the
built-in-to-dovecot SASL support, when I was actually talking about
the Cyrus SASL libraries being in the "food chain" for Cyrus ACAP/IMSP.
Sorry if I confused anyone.

>> Cyrus SASL is required to build Cyrus IMSP and ACAP, which use SASL to
>> authenticate and which can be used by the Mulberry IMAP client to store
>> address books, preferences, etc.

> Wasn't the original context of this discussion writing an ACAP server as
> part of Dovecot?

Yes, and my comment was a reply to Enrique Perez-Terron <enrio at online.no>,
who wrote:

: By the way, searchning around I found there is a companion protocol
: for storing user preferences and the like in servers. ACAP - I guess
: there must have been some discussion about that here before. Does
: dovecot plan to offer any such services?

The gist of what I was trying to say was that this idea felt to me as
out of scope for what dovecot ought to do.

ACAP (and its predecessor IMSP) are rather useful as a central
store for address books and mail user agent preferences.  (I
mentioned that I use this with my Mulberry MUA for both address
books and Mulberry preferences).

I haven't seen anyone explain the big gain would be for dovecot
to act as an ACAP service.  There are two plausible roles:

+   To maintain IMAP preference data -- not sure if this has any
    value, since dovecot already supports plenty of ways to
    store user login/password data and mailbox locations and I
    can't think of much else in the way of IMAP settings/preferences.

+   To maintain address book data and mail user agent preferences --
    to wit, something that could be used in place of Cyrus ACAP or
    IMSP.  This is more useful, but this has nothing to do with
    an IMAP service and may thus be "out of scope" for the dovecot
    project.

Still, even if these services don't have anything to do with IMAP
itself, one could make the argument that anyone who wants a high-
quality, easy-to-run IMAP server may also benefit from an ACAP server.

I'd use it -- anything that would save me from having to build the Cyrus
utilities!  :-)  But I am probably in the minority since I'm a Mulberry
user, and I don't know who else supports these protocols and how valuable
they'd really be to the dovecot community.

One of the things I find elegant about dovecot is that it strikes a
nearly perfect balance between having lots of features but staying away
from the "everything but the kitchen sink" approach of some software
projects.  I would rather have a system that did a small number of things
well than a system that does everything poorly.  Whether this is a good
idea, I don't know.  Perhaps Timo will share with us his vision on this
point.

> Or are you presenting the agonies of Cyrus SASL (which I've suffered and
> learned from) as argument FOR adding ACAP to Dovecot?

As a Mulberry user I would personally benefit from such an addition>
Nevertheless, I am disinclined to suggest it at this time.  However, as 
noted above, someone could certainly make a viable argument in favor!
And, in any case, anything that saves one from the agonies of building
and running Cyrus SASL is probably a doing the world a favor.  :-)

> Unfortunately, it seems ACAP fell by the wayside as too complicated, and
> LDAP came along instead.  Pity there's not a good, clean OSS LDAP server
> around :/

Agreed.