Jon Roma wrote:
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.
No. It's more that when the OP suggested adding an ACAP server to Dovecot, you started talking about Cyrus SASL, as if they were somehow connected, and presented it as some sort of reason to NOT build ACAP into Dovecot.
I can only see Cyrus ACAP and Cyrus SASL as strong supporting arguments TO build an ACAP server on Dovecot.
It almost seems like you're referring to ACAP as a specific application, not a protocol in its own right.
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.
Well, the scope of Dovecot seems to be expanding all the time: LDA, Auth server (with patches to Postfix to use it for SMTP Auth), and (possibly) soon a config server.
Given that ACAP uses the same basic protocol layer as IMAP, and was originally designed as a companion protocol to IMAP, I don't see it being a far stretch.
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).
And I suspect more programs would support it... if there were a less obnoxious-to-build ACAP server available.
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.
I was never under the impression ACAP was there to store details for the server to use, only for the clients/users.
- 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.
"out of scope" is a difficult call, and ideally up to Timo (who'll probably say "If the users want it...", and continue looking worn out :)
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 agree here. The way I see it, IMAP shifts the separator line, so my MUA is now abstracted from message storage. Since the details of my mail are not tied to a specific MUA install any more, why should the rest of my mail info (address books, filters, etc) be?
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.
Sadly, very few MUAs support ACAP - most likely because almost nobody implemented a good ACAP server, and LDAP somehow won favour.
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.
I do like the KISS approach. I also like the modular approach Timo has taken. It would mean an ACAP server on the same code base already has most of the work done, on the protocol side.
It would become a matter of implementing the verbs and back-end storage.
-- Curtis