Curtis Maloney cmaloney@cardgate.net wrote:
Jon Roma wrote:
Curtis Maloney cmaloney@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@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.