-- On Tuesday, February 15, 2000 9:36 AM -0800 the entity known as Randall
Gellens <randy(_at_)Qualcomm(_dot_)Com> wrote:
<begin quote>
At 9:37 AM +0000 2/15/00, Edward Hibbert wrote:
ACAP looks as though it's re-inventing another directory service
and access protocol
This perception is not uncommon, but the intent of ACAP is not to be a
directory access protocol at all, but rather a very easy way for clients
to access data on a central server that is normally kept on the local
hard drive. Client configuration and preference data, for the most part.
<end quote>
To which Matthew Wall offers this response on Thu, 17 Feb 2000 23:02:07
-0500:
I would add somewhat parenthetically is that some kinds of data -- things
like user email addresses, for example -- tends to be identical but be
treated in different ways depending on the context of management and user
access. Directory data, for instance, is a bit different from the way you
want your personal addressbooks to be handled: the example I usually give
is you probably want your Aunt Millie's address in your personal
addressbook and maybe shareable with your wife, but not in the corporate
directory.
Sieve filter strings I expect will have similar provenance -- on the one
hand, there will be times when they may best be stored as part of a
directory, others where they're appropriate to client preference data.
Speaking from the client side of things, from a client that may wish to use
sieve strings in a disconnected mode (e.g. with no LDAP server available),
but where some communication with a remote server is nice for resynching
from time to time, the ACAP model works a lot better. The email client
program treats a user-based and defined filter as yet another preference,
in effect. LDAP can be miserable if you try to overload it with too much of
this stuff.
I do agree that ACAP would be the best management route in the best of all
possible worlds, but don't really see a problem using LDAP or whatever
works in a given environment if the deployment warrants it...we've even
experimented with IMSP 8-).
- mw
PS Larry's comments are well-taken, however, about implementation humps.