[Dovecot] Documentation

[Jon Roma]

Curtis Maloney <cmaloney at 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.  :)