From: Michael Bacon (no email)
Date: Fri Nov 09 2001 - 14:30:33 EST
--On Wednesday, November 07, 2001 14:11:41 -0800 Pat Lashley
<patl+> wrote:
> --On Wednesday, November 07, 2001 04:36:59 PM -0500 Lawrence Greenfield
> <leg+@andrew.cmu.edu> wrote:
>
>> [...]
>> And on a mostly unrelated note, what is the current state of the
>> ACAP daemon? Is it sufficiently featureful and stable to be
>> deployed in a small production environment? If I want to test
>> it out, should I go with the latest tarball, or get it from CVS?
>>
>> We don't recommend deploying ACAP; it seems unlikely to attract much
>> client implementation at this point.
>
> Isn't that sort of a vicious circle though? Don't bother to
> deploy it because there isn't much client support because it
> isn't widely deployed... Or are you saying that it's just
> too early in the development cycle?
>
> Or is there some other reason why clients aren't likely to
> support it?
>
I'm going to speak my mind here, though I apologize if I step on anyones
toes. We've been slowly trying to evaluate getting ACAP to a point where
it could be deployed for a variety of uses, primarily the Cyrus Murder
aggregator technology.
The problem with ACAP currently seems to be that there are no good server
implimentations. Last I checked, the Qualcomm people had one which only
partially implimented the standard, and there was another commercial one
somewhere that was only available with the full MTA package. The only
available open source one is the cyrus sml-acapd, which unlike every other
cyrus project product, is completely unusable. It's written in SML, an
obscure language that hardly anyone understands, so the core workers on the
project get almost no outside help. In addition, if I understand the
various web pages correctly, the principle author has left CMU. The server
frequently mishandles or corrupts data, crashes on basic ACAP commands, and
its storage mechanism and ACL handling systems are a mess. My impression
is that it is essentially unmaintained -- I actually wrote a patch to its C
front end to handle STARTTLS code, and wrote to the given addresses listed
in the distribution to see if anyone was interested in them. I never got a
reply.
Cyrusoft's Mulberry and Qualcomm's Eudora are ACAP enabled already, and
with a good server available I have to wonder if it might find its way into
the open source browsers as a place to store preferences, addressbooks, and
bookmarks. Consequently, we're considering writing a new server
implimentation in-house in a more widely used language, such as either C or
Java, and releasing it as open source code.
I don't mean to point any fingers here -- certainly not at the CMU folks.
After all, it's not their job to provide the rest of us with
production-class servers for every protocol out there. However, we're
not quite ready to give up on ACAP, and I don't think it's fair to say that
client support is the only problem. If there were a good open source
server, I imagine it might spur at least some client development.
Michael Bacon
Duke University
|
|
|