Ok, we're all interesting in getting ACAP servers out there.
I'd love to just use ACAP. However, defining an "ACAP profile" to
handle Sieve scripts isn't as easy as it sounds.
I want to be able to share my Sieve script with my coworkers, but
not my boss (I filter all of his mail).
Since we don't want the ACAP server and IMAP server necessarily
sharing the same filesystem, I want my IMAP server to be able to
open contexts on my ACAP server that stores the scripts. This way I
don't have to do an ACAP search for every message delivery but I
won't use out-of-date Sieve scripts.
Ok, great, now we need ACLs and contexts. I'm sure I can justify just
about any other ACAP feature you want me to.
We (CMU) have a working ACAP server. I'm willing to start putting
Sieve scripts on it next week. I'd be extremely happy to say "we're
going to use ACAP" and see people implement ACAP servers to store
I'm not sure this is going to encourage deployment of Sieve.
Or, rather: is anybody going to develop an ACAP server to deploy Sieve
in their products?
Date: Mon, 14 Feb 2000 16:53:01 -0800
From: Randall Gellens <randy(_at_)Qualcomm(_dot_)Com>
At 08:55 AM 2/8/00 -0500, Barry Leiba wrote:
>I have to say that this whole thing seems a little excessive, considering
>the statement that this is an interim solution anyway:
I agree. I don't think it's a good idea to go the yet-another-protocol
route unless it moves us closer to where we want to be.
My proposal all along has been to use ACAP or a subset. We have prototype
implementations of an ACAP profile for Sieve (along with a Sieve engine)
running on NT and Unix, and a prototype Windows GUI that manages scripts.
By using an ACAP profile, both client and server support becomes pretty
easy, and the client can talk to a full ACAP server just as well as a mini,
Sieve-only one. So we get rapid deployment and move closer to a real
solution (full ACAP servers).