ACAP is a service designed to store user preferences.
Here are some good bits on both.
----------------------------------------------------------------------
>>From ietf-asid-errors@umich.edu Thu Feb 20 18:53:56 1997
>Sender: howes@netscape.com (Tim Howes)
>Date: Thu, 20 Feb 1997 14:19:50 -0800
>From: Tim Howes <howes@netscape.com>
>Organization: Netscape Communications Corp.
>To: Jack De Winter <jack@wildbear.on.ca>
>CC: ietf-asid@umich.edu
>Subject: Re: REPOST: LDAP and ACAP, from an IMAP point of view
>References: <3.0.32.19970217153812.006ec808@lacroix.wildbear.on.ca>
>
>Jack De Winter wrote:
>>
>> okay, I am on the IMAP list, as well as the ACAP list,
>> and I am trying to figure out the entire ACAP versus
>> LDAP thing.
>>
>> Would someone be able to help me out by clearly stating
>> what the design goal of LDAP is, and how extending LDAP
>> to cover what ACAP is covering is a good idea? I know that
>> this may be a volatile subject, but I simply want to know
>> where LDAP is right not, and how LDAP could be made better
>> or worse by going into ACAP territory (so to speak).
>>
>> >From my limited reading and exposure on the subject, I thought
>> that LDAP was supposed to be used for the broadcasting of
>> read-only directory information, and limited changes to some
>> of that information. For example, an addressbook or a company-
>> wide lookup database (I want to send mail or phone Phil Smith,
>> please give me the pertinant information, thanks).
>
>Sorry for not responding sooner. Here are some thoughts
>on ACAP and LDAP.
>
>When I look at ACAP and LDAP, I see like 90% overlap.
>They both provide an an attribute/value-based storage
>mechanism. They both allow you to search the information
>they store. They both allow you to update the information.
>Etc. Doing this basic stuff is where the majority of work
>in providing any service like this lies.
>
>Where do they differ? It's helpful to understand where
>they come from first. ACAP comes to its current general
>state from a more specific one, aimed at providing these
>services in support of IMAP. LDAP comes to its current
>state from one where it was tied to X.500. Both ACAP and
>LDAP suffer from the perception of their roots.
>
>One claim you'll hear is that ACAP is targeted at less
>structured information, less central administration, more
>autonomous control by applications and users, and that
>LDAP is not. This is not really true, and this is where
>LDAP suffers from the perception that it's restricted
>to front-ending X.500, and X.500 suffers from the perception
>that the model it defines is only good for the globally
>managed white-pages-style directories you're used to seeing.
>
>There are three issues at the heart of this:
>
>1) Schema. Perception: LDAP schema must be centrally
>managed and controlled and adding additional elements,
>say for your application, requires contacting some central
>administration. Fact: Schema in LDAP is in the hands
>of each server. If a server wants to allow clients to
>store anything they want, without applying any schema
>rules, it's free to do so. Yes, there are common sets
>of schema elements defined for white pages and other
>applications that can benefit from such things. No,
>your application doesn't have to use it if it's not
>required.
>
>2) Namespace. Perception: LDAP names are all hierarchical
>and step one to bringing up an LDAP directory is figuring
>out what your "root" is and registering yourself with some
>central naming authority - kind of a pain if all you want
>to do is store your preferences. Fact: LDAP has no such
>restriction. If you want to configure your LDAP server to
>hold entries directly under the root, you can easily
>construct a flat namespace, or a hierarchical one of your
>own that starts from the root. The protocol makes no
>requirement about this. The namespace you've see in the
>LDAP/X.500 white pages world is not one you need to tap
>into to provide a preference store.
>
>3) Data distribution. Perception: To use LDAP as a preference
>store means extending people's existing white pages entries
>with attributes to store preferences. Since these two types
>of data seem to have different requirements, read/write
>ratios, replication requirements, etc., this appears bad.
>Fact: There's no need to have one gigantic uber-entry for
>each person in the directory, certainly not as far as LDAP
>is concerned. A better strategy that I'd advocate is using
>LDAP much the same way that ACAP has been proposed: have
>a separate server co-located (or not) with your mail server
>or other related things. Yes, I'd want a pointer in my
>LDAP entry in the corporate directory to my LDAP entry in
>the LDAP "preference server", but no, there's no requirement
>for them to be the same.
>
>These problems of perception can be dealt with easily by
>a little education on both sides. More fundamental questions
>are raised by considering the real areas in which the
>two protocols differ, and there are some.
>
>ACAP provides built-in support for quotas. LDAP does not.
>What would LDAP need to handle this? I'm thinking just an
>operational attribute that expresses how much over/under
>quota a user is, but maybe I don't fully understand the
>problem.
>
>ACAP provides primitives for off-line operation, and
>syncing up once you reconnect to the network. LDAP does
>not. How hard would this be to do in LDAP? I don't fully
>understand how what ACAP has solves this differently
>than an LDAP client caching data and defering update
>operations until it connects back up, which can be
>done today. I may need some education, though.
>
>There are probably a few other things, as well.
>
>The danger in using LDAP instead of ACAP is made in
>the "LDAP is my hammer and every problem is starting
>to look like a nail to me" argument. In other words,
>the problems the two protocols address are different
>and deserve different protocols as solutions, rather
>than one uber-protocol to solve everything. It's a
>compelling argument, but only if you buy into the
>premise and into some of the misconceptions about LDAP
>that I mentioned above.
>
>The other side of the coin is that if you believe,
>as I do, that there is tremendous overlap in the two
>protocols, there is obviously a real cost to developing
>and deploying an entirely new protocol and infrastructure
>to support it. If you can leverage existing LDAP code
>and installed base, things get a lot easier, from
>development, to deployment, administration, etc. Do
>we want to end up with a different directory protocol
>for every kind of application? White pages, yellow
>pages, configuration storage, preference storage,
>document meta-information, etc. etc. Obviously not.
>
>So where does this leave us? Well, Chris Newman and
>I have had it on our plates for a while now to sit
>down and write up some kind of document that describes
>where we think the two protocols are going, how they
>differ, might coexist, etc. Neither one of us has
>had time to push this effort, unfortunately.
>
>But having learned more about ACAP over the past
>few weeks, and having thought about things a little
>I guess I've come to the following conclusion. There
>are two things I could see happening that I'd be
>willing to support.
>
>1) Use LDAP to solve this problem. If we need to add
>a couple of extensions to do it, that still seems
>easier to me than developing a whole new protocol
>from scratch. Seems like we should at least try, given
>the cost of the other path. If we go this route, and
>it works, there's no need for ACAP.
>
>2) Radically simplify ACAP so it really provides a
>simple store/get service for configuration information.
>Much of the complexity it has is in trying to do
>sophisticated search and update, access control, etc.
>None of this stuff is needed if it's really meant to
>just solve the configuration access problem. LDAP can
>do this too, of course, but I can certainly see some
>benefit in defining a new very simple (authenticate,
>store, retrieve) protocol for this purpose - no sense
>making people implement LDAP if this is all they want.
>
>So, that's a brain dump from me on the subject. I don't
>want to touch off a storm of controversy, but I do
>think it's time we started thinking about these issues.
>Sorry for being so long-winded, but I hope this helps
>clear up some of your confusion. I'd be very interested
>to hear what other people think about this too.
> -- Tim
>
>
>
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873 http://www.wildbear.on.ca/
Author of SLMail for 95 & NT (http://www.seattlelab.com/)