From owner-freebsd-chat Tue Sep 30 19:30:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA10075 for chat-outgoing; Tue, 30 Sep 1997 19:30:35 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA10070 for ; Tue, 30 Sep 1997 19:30:32 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id TAA11395; Tue, 30 Sep 1997 19:29:54 -0700 (PDT) To: Chuck Robey cc: Mike Smith , Peter Korsten , chat@FreeBSD.ORG Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) In-reply-to: Your message of "Tue, 30 Sep 1997 21:13:14 EDT." Date: Tue, 30 Sep 1997 19:29:54 -0700 Message-ID: <11391.875672994@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Doing something based upon HTTP means that you'd get character mode and > browser inerfaces for free, essentially. Is this also true? I want to > see if these questions can be ansswered separately, Mike, so that the area > of the problem can be cut down. I don't mean to speak for Mike, but I still don't think that everyone's quite getting the point that Mike or I have been trying to make here. We have a big engineering task: How to front-end a wide variety of system installation and administration tasks so that the user isn't stuck trying to figure out how to use arcane commands like disklabel, newfs or pkg_add if they really don't want to. I think we're all in general agreement on the size and shape of the problem space. So, in the spirit of progress, someone like Mike here tries from time to time to break the stalemate on this task by attempting to divide the problem space into more finite chunks, the very first chunk generally coming up as "What's the interface going to look like given our various constraints on size, allowable external dependencies, etc?" And this is where we've consistently bogged down in the past. We couldn't agree on how to handle the interface, the pack quickly dividing into HTML advocates who cite the browser as the ultimate GUI etch-a-sketch (and heck, that it is) and minimalists who really really want their serial console installations at various cold and drafty co-location sites to be no more miserable than necessary. This time, Mike tried a new tack in pushing the discussing more towards his Juliet spec and settling more of the "base questions", like "what's the new packaging API going to look like?" or "how will the system be extensible for highly custom installations?" but it seems that, inevitably, we're back at the "What's the interface going to look like?" question again. Resistance Is Futile, you WILL discuss the user interface technology. ;-) Seriously, it would be nice if we could just forget about the stupid GUI technology for a bit here and focus on the underlying *UI independent* technologies like Juliet so that we can make some actual progress without getting locked into this debate again before we're even out of the starting gate. Heck, if you really want a brief and just summary of our UI interface options that's pretty easy to do since there are only 3: 1. A complete homebrew generic curses / graphical toolkit which is intelligent enough to switch UIs depending on the kind of display available to the user. 2. Something so disgustingly turbo-CUI that even running it in CUI mode in an xterm window is considered acceptably usable by the graphics display users. 3. HTML, lynx & netscape providing the "generic UI" component. Option #1 we've been evaluating for a long time and, frankly, every available option examined to date has turned out to suck in some unusably extreme way. Unless someone's hiding God's generic UI toolkit somewhere and just hasn't shown it to us yet, I don't see much hope for this option. Option #2 seems to be TurboVision (ports/devel/tvision) and only TurboVision, the only problem with that so far being the fact that most of us don't like to write in C++ and TurboVision is quite thoroughly wedded to that language. Someone was contemplating a TCL API to it, something which would reduce the pain considerably for us C/TCL programmers out here, but I think he wisely ran away for awhile. ;) Seriously, I'm not sure how this option is going to pan out but it's the only entry in its column, so we should probably at least look at it. ;-) Option #3 is to somehow use a mini-embedable web server, a stripped-down Apache or some other server framework to create a system which can be driven entirely from a reasonably capable HTML browser. This approach has already been taken by various parties with reasonably mixed results - some of their interfaces seem quite usable and others are just plain ugly. The security implications in each case are not clear (I rather suspect that the lion's share of such interfaces currently run with very little security and assume a trusted communications path, e.g. no sniffing). So, now that I've gone and summarized what I feel to be the only possibly UI options, which one do I think would be best for us? How the hell should I know? What I do know is that all 3 of these approaches have one thing in common: They all need to bang on your system's configuration. Think about it. :-) We need to step away from the interface question for a bit and just focus on creating mechanisms for solving the following problems: o Proper installation *with audit trail* of all software on the system - this requires the merging of "packages" and "distributions" into a common distribution package. o Proper abstraction of the system's configuration metadata along with authentication mechanisms flexible enough to allow for individual permissions on the data. Your UI, be it web or Tk based, would simply be one of many potential clients of such a configuration server. o Creation of an installation and configuration *framework* vs the monolithic utility we have now. Such a framework would allow vendors to drop their own installation procedures into the system for more seamless integration of their various tools and also allow us to extend "setup" more modularly as time and enthusiasm allow. Setting up samba or apache or any such fancy utility should involve little more than running its installation "applet" inside the installer's framework, said framework providing a rich library of methods for querying the user for specific information, doing authentication, talking to the configuration server, etc. Any of these 3 problems can not only be solved in a UI-neutral fashion, they *should* be since it leaves the door open for us to follow whatever the next trend is in 3D interfaces or something ("Oh man, what do you mean I can't just walk through FreeBSD's install with my TurboVR goggles and my dataglove? Everyone else's installer does! You guys are lame!" :-). Jordan