Date: Mon, 13 Jan 1997 20:03:10 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: config@freebsd.org Subject: Re: Config Manifesto comments? Message-ID: <21469.853214590@time.cdrom.com> In-Reply-To: Your message of "Mon, 13 Jan 1997 18:36:26 %2B1030." <199701130806.SAA16651@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > what's more, Juliette would have to know about the documentation
> ^^^^^^^^ Juliet. 8)
It's been too long since I read any Shakespeare. :-)
> 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.
Ah, but it's really not, you know.
Consider one of the services on your list of front-end targets, the pw
command. I want to write a front-end to pw, so I come up with a list
of properties for defining a user and I hook it into the relevant part
of Juliet's property list tree. Now I run over to the Romeo side and
I build a screen containing the superset of all fields you need to
fill in for pw add/change/delete requests, plus some docs which
describe them, and I'm done, right?
OK, now 2 weeks later someone adds login class configuration to the pw
command and I've now got this extra field for class information. I
run back to Juliet and add in the new property, go over to Romeo and
add a new item to the user admin screen for it, also amending the
related docs to indicate that there's this new user class field.
That just seems like just too much running around to me, and it
involves a two-way sync for *every* change, which adds up.
What I'd prefer to do would look more like this:
I want to write a front-end to pw, so I come up with a list of
properties which define a user, PLUS I implement a property which
describes the layout of the property editor for that set of
properties. I also provide a documentation property for the toplevel
UI dialog (probably just a long string of text). All of this
information is grouped together in one location in Juliet's
configuration database.
Also, when I say "implement a property which describes the layout of
the property editor", what I mean is one of several possible options:
1. A string simply containing the Tk code to execute in the context
of Romeo to instantiate the dialog. This sure opens up a lot of
room for programmer abuse ("something Juliet said just brought
Romeo down in flames!"), but then we can always use Tcl 8.0's ability
to run sub-interpreters for firewalling the Juliet code (and I suppose
a proper catch would largely prevent the "down in flames" syndrome).
The advantage is that it would be bloody easy.
2. A TBL-style layout specification (directly supported by Tk's new
row/column layout manager BTW). This also assumes that each of the
user properties contains enough type information that Romeo knows
what kind of UI object to create for each. Items would be
instantiated in the order they were returned from Juliet, using
the layout specification to tell the containing row/column widget
how to lay them out.
Now let's say my 2 weeks are up and login classes arrive in the 2nd
scenario. I go back to Juliet's database and I add the user class
property, amend the doc property to mention it and tweak the
associated Tk script or TBL property to include a new UI field. Still
the same basic work, but I'm doing it all in the context of Juliet - I
don't need to mess with Romeo at all.
> 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
Yes, I understand how that would be nice. However, I'm also of the
opinion that retreiving a new page to update the data after hitting
the "Go" button would not be so heinous that I couldn't live with it
in the first version. The server should be able to cope with the idea
of a dumb browser with no client-side intelligence, and which needs to
be talked to in lock-step, just as well as it can cope with the idea
of a client which only talks to it occasionally, doing its own
internal validation based on the various HTML constructs it's seeing.
Since our install is no longer a hierarchy so much as a mesh, we can
also (if we like) use some of the more advanced apache server features
which allow you to switch the user to a wholly different set of pages
based on the browser they're using. The HTML itself really determines
what is asked of the browser, and we can generate or direct the user
at whichever data we like, so I think we can tailor things as special
case scenarios come up.
As we evolve the system, more clever things can be done and, perhaps
ultimately, all that interactivity won back with Java in a world where
a java capable browser is freely available. Being willing to live
with the shortcomings of the current world would, however, at least
allow us to make some rapid progress now. :-)
> ... only that Netscape wasn't a shippable option. "You need Netscape
> to run our spiffo tool, but we can't give you that.". *ponder*
"but which the other 99.99% of you Internet connected people can
easily fetch from ftp://ftp.netscape.com/pub/foo/bar. Those of you
who aren't Internet connected, go visit a friend who is and stick it
on some floppies."
I really don't see this as such a hardship. Even when I lived in the
Irish boonies I still had Internet access, and that was years ago.
Now even the Irish boonies have *multiple* providers to choose from! :-)
> Urk. That's a long step forwards from "if you don't have a GUI interface,
> get one and come back".
Well, I'm still yet to be convinced that version 1.0 needs all the
client-level scripting. If you can be convinced that page refresh
isn't too hideously obnoxious, I can in turn probably show you a
colorized, function-key using version of lynx which doesn't look all
*that* horrid if you lay our the HTML with half a care. If it was
between that and nothing, I'm sure more than a few users would use it.
> *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 like the idea of not writing the UI specification screens in HTML at
all. HTML is a poor source format, and there is far too much grunt
work involved in doing anything truly sophisticated with it. All the
form posting and validation crap should be handled by the framework,
not the front-end writer.
To me, that means coming up with a meta-markup language which allows:
o Embedded HTML, for when "ya just gotta."
o A representation of variables, both read-only and read/write.
o A representation of inline function calls and the data type
the return.
o The specification of field-validators for any embedded variables
in the page.
o The URL of a help screen (so we can construct standard "Help
buttons") for all pages.
>From that, you generate the HTML and whatever data structures are
required for keeping track of all the data items in it, so the server
framework can look up the appropriate things when the user selects an
"object" in the dynamically generated 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)
Grrr, you chose that example on purpose! :-)
> 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?
Well, before we get too carried away in defining the "top level"
screens, we should clarify that there will be not just one, but
several top screens. When Juliete-with-http-port starts up at
installation time, the home page will point to an installation menu
somewhat akin to what sysinstall provides now. After installation,
the Juliet server which starts up will point to a different location,
and now we have a "administration page" as the top level.
Those I think we can evolve as we go along, what we're looking more
for at this stage is an idea of how complex those screens will be, and
how many different types of "GUI object" we'll need, be the screens
either HTML or Tk based.
> - A splash screen (default entrypoint), with links to :
> - Getting Started with FC'T.
> - Common Tasks.
> - Functional Index.
> - Documentation Index.
> [detail snipped]
Sounds good to me.
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21469.853214590>