[Dovecot] Documentation

[Curtis Maloney]

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 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.

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