From owner-freebsd-hackers Fri Jan 30 16:26:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA00251 for hackers-outgoing; Fri, 30 Jan 1998 16:26:19 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA00243 for ; Fri, 30 Jan 1998 16:26:14 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id QAA07009; Fri, 30 Jan 1998 16:27:01 -0800 Date: Fri, 30 Jan 1998 16:27:00 -0800 (PST) From: Alex Belits To: Terry Lambert cc: Thomas David Rivers , mike@smith.net.au, capriotti0@hotmail.com, capriotti@geocities.com, hackers@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin In-Reply-To: <199801302350.QAA12695@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" On Fri, 30 Jan 1998, Terry Lambert wrote: > > Computer Reseller News (www.crn.com) just published a lead article > > indicating LDAP is soon to be dead... People are finding it to be too > > ill defined producing too much incompatibility. > > > > Based solely on that article, since that's all I know - I'd suggest staying > > away from LDAP until a presumed newer definition materializes. > > I'd say the death of LDAP is much exaggerated. I think CRN also > had an article on how NT was going to kill UNIX, didn't it? ;-). "Never trust a computer-related analysis article published by a company that uses NT as the server for it" ;-) > I have an LDAP server here with all of the varios fixes, except for > the cryptographic stuff, already integrated. I can send out a mega > patch if you are serious about hacking on it for FreeBSD. > > One thing LDAP is currently missing is a transactioning mechanism. > You can fake this *if*: > > 1) You are guaranteed your last request is committed before > your next request. > > 2) You use a reference object. > > Ie: I have a user record for uid 117; it looks like > > [atomic transaction over LDAP skipped] Yes, but why? My proposal to use HTTP is based in part on the ease of transactions handling over it. HTTP doesn't necessarily mean HTML and interactivity, it can, say, use URL-encoded list of key-value pairs symmetrically (both from server and to server as opposed to HTML form from server and URL-encoded form upload to server) and provide HTML only if the user is working in a browser. That will allow more flexibility, easier configuration replication, etc. -- Alex