Curtis Maloney cmaloney@cardgate.net wrote:
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.
Hi, Curtis.
Sorry; I didn't mean that, and looking again at the mail I sent, I can see that it didn't come out at all right. :-(
I can only see Cyrus ACAP and Cyrus SASL as strong supporting arguments TO build an ACAP server on Dovecot.
Assuming that there's justification to do ACAP, I agree wholeheartedly. An implementation that doesn't require pulling one's hair out to install has a lot better odds of widespread adoption.
It almost seems like you're referring to ACAP as a specific application, not a protocol in its own right.
No, I know the difference. To date, I am aware of exactly one ACAP implementation, but that doesn't change the fact that it's a protocol. :-)
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.
Maybe not. I guess it depends on how the cost/benefit ratio plays out. ACAP would be nice to have, but in my view, the world needs the IMAP server part of Dovecot a LOT more than any of the other pieces.
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.
Yes, that's the old chicken and egg problem! Aside from the frustration with dealing with the ACAP/IMSP builds, it's sort of frustrating that work on ACAP's apparently petered out especially since its potential utility is so obvious. But as you noted, LDAP probably stole the spotlight.
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.
I, perhaps incorrectly, assumed from the question that someone was inquiring about storage related to dovecot's "primary mission" as an IMAP server, which didn't seem particularly useful to me. I didn't really think outside that context until you and I got into this discussion.
- 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 :)
Exactly. And one question I could see being asked is "Is this something that should be part of dovecot, or is this a separate project that dovecot could benefit from?" And then there's the whole chicken and egg thing with having applications that can use ACAP to justify the work....
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.
Agreed there. Maybe now we need built-in LDAP support too -- uh, oh ... I think I'm opening a can of worms. ;-)
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.
Agreed with respect to KISS and modularity.
It would become a matter of implementing the verbs and back-end storage.
That could make it promising.
Anyway, it's interesting to see discussion of ACAP. Some days, I feel like the only person on the planet who's heard of it. :)