From owner-freebsd-config Mon Feb 2 11:12:06 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA16051 for config-outgoing; Mon, 2 Feb 1998 11:12:06 -0800 (PST) (envelope-from owner-config) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA16015 for ; Mon, 2 Feb 1998 11:12:02 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA23333; Mon, 2 Feb 1998 12:11:41 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd023301; Mon Feb 2 12:11:39 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id MAA08865; Mon, 2 Feb 1998 12:11:26 -0700 (MST) From: Terry Lambert Message-Id: <199802021911.MAA08865@usr04.primenet.com> Subject: Re: WebAdmin To: abelits@phobos.illtel.denver.co.us (Alex Belits) Date: Mon, 2 Feb 1998 19:11:26 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com In-Reply-To: from "Alex Belits" at Feb 1, 98 11:27:29 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I only mean that HTTP protocol provides means for transactions handling > implementation that don't need an identifier being passed explicitly. It's > definitely possible to use any other protocol or invent new one that will > provide the same thing with (your example with LDAP) or without > identifier, however I think that HTTP provides exactly what is necessary > without increasing the number of protocols involved. OK, I think that you may be missing where I'm putting LDAP. I am not presenting LDAP as a wire protocol, but as an API. This would work better with a whiteboard, but... ,---. ,---------. ,---------. ,---------. ,---------. |R | | Browser | | JAVA | | | | | |e A| `---------' `---------' | TEXT | | X | ... |m d| ,---------. ,---------. | UI | | UI | |o m| | HTTPD | | JNI | | | | | |t i| `---------' `---------' `---------' `---------' |e n| ,----------------------------------------------. | | | LDAP Client API | | | `----------------------------------------------' | `-----------------------. ,----------------------. | Network connection | | UNIX Domain socket | `---------------------------' `----------------------' ,----------------------------------------------------. | LDAP Server | `----------------------------------------------------' ,--------------. ,-----------------------------------. | LDBM Backend | | Zillions of FreeBSD files Backend | `--------------' `-----------------------------------' > As for text console and no network connection, HTTP is perfectly usable > over loopback network interface with text-mode client for user interface, > so user-interface part (if necessary) can be done through it, too. Again, > it can be done through locally running application with any kind of user > interface or none at all with nothing related to HTML, or remotely > running the same application, or whatever else -- just the possibility of > adding HTML user interface without introducing new protocols and > authentication systems to existing ones makes HTTP a bit better choice for > internal protocol. At least, it will be more manageable, secure, suitable > for large network or single non-networked host, and consistent by design > than anything NIS-like (network administration) or SMIT-like (local > administration). The issue isn't the wire protocol; the issue is building a common API to the "Zillions of FreeBSD files". LDAP is an API for accessing directory schemas; why reinvent another protocol? Alternately, you could use ACAP. Unfortunately, the only implementation I know of that runs on FreeBSD uses g++ 2.8.0, the Moscow center for SPARC computing's STL with modifications to work with FreeBSD's Draft 4 Pthreads which haven't been upgraded to standard Pthreads yet, libg++ (the templates for which may constitute sufficient code in header files to fall under the "code in headers" clause of LGPL, etc.. Not to mention that Jeremy Allison and I haven't sent our patches back to the CMU folks yet... ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.