Date: Tue, 30 Sep 1997 19:29:54 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Chuck Robey <chuckr@glue.umd.edu> Cc: Mike Smith <mike@smith.net.au>, Peter Korsten <peter@grendel.IAEhv.nl>, chat@FreeBSD.ORG Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) Message-ID: <11391.875672994@time.cdrom.com> In-Reply-To: Your message of "Tue, 30 Sep 1997 21:13:14 EDT." <Pine.BSF.3.96.970930210221.21190K-100000@Journey2.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11391.875672994>