Date: Mon, 13 Jan 1997 18:36:26 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: msmith@atrad.adelaide.edu.au, config@freebsd.org Subject: Re: Config Manifesto comments? Message-ID: <199701130806.SAA16651@genesis.atrad.adelaide.edu.au> In-Reply-To: <15352.853137749@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 12, 97 10:42:29 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard stands accused of saying:
> them have their strengths and weaknessess. I'm just trying, at this
> point, to figure out which approach has the greatest likelyhood of
> actually being implemented in this coming year and also which is the
> most future-proof, since we're not likely to be doing all of this a
> 3rd time. Just getting it done a second time has already taken years! :-)
*chuckle* Fair enough.
> Doing all of this with Tk would require a fair bit more work - we'd
> need to select a help system (I kind of like the one in BLT), clone
> docs from the Handbook and Tutorial into it (or write/incorporate an
> HTML browser widget for Tk and move in the other direction :-) and,
I'd go for the second, given that we could just filch WebTk. Then we'd
have an authoring tool as well. But regardless, I take your point.
> what's more, Juliette would have to know about the documentation
^^^^^^^^ Juliet. 8)
> properties for each UI screen or you could never keep them properly
> associated when changes were made.
Documentation is a UI issue, so it's Romeo's problem. Juliet exists
as a means to frob logical configuration entities on the remote system.
> I dunno, HTML just sounds a lot easier to me! :-)
Maybe it is. Ease isn't something I'm well-placed to judge there, as I
don't speak HTML with any serious degree of fluency.
> > But it doesn't. Just keep reminding yourself that the user _isn't_ going
> > to be using Netscape for their interface. Think Chimera, for an LCD.
>
> Ok, I just tried out version 1.65 on the FreeBSD pages. It didn't
> look particularly great, and something's funky with its popup choice
> menu handling (everything's double-spaced), but the forms look
> usable enough. What does it not do which you need, exactly?
Frames? Java? Tables?
> I'd still like to hear more about why you feel client-side scripting
> is so necessary to providing a functional interface. Note that I am
> saying "functional", not "snazzy."
My basic requirement is "interactive". If the user frobs a control that
doesn't actually require any thought on the part of the server, I'd like
the client to deal with it, rather than have to retrieve a whole new
page. If you view the user-client-server interaction as a path with
data moving back and forth between various parts, HTML cuts the path
at one of its widest and busiest points.
Why do you think that Java and other client-side scripting languages are
such hot property?
> Huh? Not necessarily. You can have your non-commmercial web
> browser running with multiple pages open, and I also never said you
> couldn't load netscape after you got your system up, simply that we
> needed to get through "install time" using simpler HTML-based
> screens.
... only that Netscape wasn't a shippable option. "You need Netscape
to run our spiffo tool, but we can't give you that.". *ponder*
> decent browser, you don't visit that page, sorry. Get a better
> browser and come back.
Urk. That's a long step forwards from "if you don't have a GUI interface,
get one and come back".
> that I give up all thought of using that icky HTML stuff, but since
> we're just debating intangibles here, I say that my intangible can
> beat up your intangible and so there! :-)
Fair enough.
> I dunno, playing the other side of the argument for a second here, how
> long do you think it would take you to code up a prototype? How many
If I wasn't working on anything else, perhaps a week or so.
> properties will Juliette try to support in the first version, and how
Not many. Probably a single proof-of-interface module and a few
submodules.
> will Romeo determine the composition of its various configuration
> screens?
If we accept the Tk mandate, they'll be hardcoded. I'd expect that
the client UI code would be prone to serious morphosis in the early
evolutionary stages.
> Will Juliette feed Romeo raw Tk code representing the
> interface to be created, or what exactly?
No. Juliet provides the backend primitives used by the code in the
modules in Romeo to perform their configuration changes.
> How will the templates be
> written? How will Romeo know the set of properties managed by a given
> copy of Julliette, so that he knows to construct menus for them?
Version numbering on a per-module basis. I wasn't planning on supporting
incompatible installations 8)
> I'm willing to dive in and help you code this, heck, I just want to
> know where you're going first! :-)
Half the time I don't have the faintest idea where I'm going, because
nobody seems to care 8( I've been trying to find time to work on a
frontend to 'pw' that might give some idea of what I was getting at,
but the weekend and the weather haven't conspired to help there.
I realise I'm taking a currently-indifensible stance 8(
> Now if you asked me those same questions about an HTML based system, I
> could answer them without much thought. One of the advantages of a
> highly-constrained system is that it makes most of the implementation
> decisions pretty obvious. :-)
*laugh* Ok; let's assume I roll over and play dead on the HTML issue.
We can squash the security squawks with ssh and port mirroring, so lets
assume that we have our config server offering http services on some
known port on the system. What drives the generated output? Is it all
constructed by code on the fly? Is the code triggered by special tokens
in template pseudo-html?
I have to confess that the stateless nature of the http interactions
causes me some concern, but I guess we can do at least as well as NFS
does 8)
> > I'm sure there will. You can bet your (whatever) that they won't match
> > our license expectations though, right?
>
> I wouldn't be too sure of that at all.
I would be very glad if something like this were to surface.
> Why don't we work from first principles and define the system in terms
> of its objectives rather than debating this on a purely ethereal
> plane? What do we want to see here, and what should it look like?
Oh dear, a top-down designer. 8) I prefer to start from the bottom and
use the basic elements available to define the scope within which the
top can be specified.
What can be done with HTML and a browser is however probably a better
place to start, so let's get specific. Let's see, how will we lay out
the FC'T?
- A splash screen (default entrypoint), with links to :
- Getting Started with FC'T.
- Common Tasks.
- Functional Index.
- Documentation Index.
- Getting Started should cover the use of the browser to navigate,
any deviations from expected "web norms", the evilness of proxies,
etc.
- Common Tasks :
A list built from 'common tasks' modules, eg.
- Installing/removing packaged software.
- Adding/removing users.
etc.
- Functional Index
A heirachial list of functions exported by modules, grouped by ???, eg.
- Network configuration.
- Interfaces.
- Routes.
- Daemons.
- Mailers.
- NFS.
etc.
- Documentation Index
A heirachial list of documentation exported by modules, as well
as links to the handbook, etc. Documentation should also be
linked to by modules directly.
As far as I can see, specialised tasks like installation would best be
managed by specially-constructed miniwebs, linking to modules as
required.
> Jordan
--
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701130806.SAA16651>