From owner-freebsd-config Sun Jan 12 02:29:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id CAA19706 for config-outgoing; Sun, 12 Jan 1997 02:29:49 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id CAA19701 for ; Sun, 12 Jan 1997 02:29:46 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id CAA19580; Sun, 12 Jan 1997 02:29:38 -0800 (PST) To: Michael Smith cc: config@freebsd.org Subject: Re: Config Manifesto comments? In-reply-to: Your message of "Sun, 12 Jan 1997 01:12:29 +1030." <199701111442.BAA08271@genesis.atrad.adelaide.edu.au> Date: Sun, 12 Jan 1997 02:29:38 -0800 Message-ID: <19576.853064978@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > No; redbacks are venomous spiders, a somewhat larger relative of the > beastie you call the "black widow". They're aggressive and, with the Oh my! That's just great. Aggressive, venomous spiders. If there are two qualities I most abhor in a spider, it's a sack of venom or an attitude. To have both is really bad luck, you have my full sympathy! :) > Well, I'm happy to be convinced otherwise, but I remain skeptical. If > you can come up with something that can handle interactive activities, > and asynchronously-posted server-side events without a client-side > scripting language, then I'll happily go along with it. Well, define "interactive activities" please. :-) Naturally you're not going to be able to do cute shaded draggy-bars and stuff in HTML, but you can certainly do forms and menus which provide the same basic functionality for the things you want to control (like filesystem sizes), just not with quite so much flash. I can do without the flash if it buys an easily distributed management station capability and provides the closest thing to a "standard L&F" these days. And doesn't server-push buy you a reasonable facsimile of async server-side events? Just think of all those cameras. It's crude, but it basically works. > I simply fail to see how a fill-out-the-blanks interface, which is all > that HTML can offer, is going to provide this, and I refuse to > subscribe to the 20-billion-flies argument. One man's 20 billion flies is another man's principle of least surprise. :-) > > Also, Netscape 4.0 for BSD/OS will be linked shared so we won't be > > able to run it anyway. With 4.0, it'll be back to the Linux netscape > > for us, I'm afraid. > > Well that's just bloody wonderful, isn't it? I can just guess how > well _that_ is going to be received. 8( Well, I'm going to make one last-ditch effort before giving in to that most contemptible of fates, but naturally no guarantees on that. They'll probably just blow me off. :( > The only thing that we win on using an HTML interface in this case is > the ability to display on non-x-capable (Windows, Mac) systems. I Not *just* that, even when running locally it provides you with a decoupled GUI interface, meaning one less piece you have to worry about, and you just let someone else sweat the browser (and there will be new and interesting browsers coming out for some time to come), concentrating instead on the internal structure and the implementation of new front-end modules. Running in the same direction as the other rats also has certain advantages - there's a huge and rapidly growing pile of HTML support code for doing all sorts of clever CGI things, and pre-existing familiarity with HTML trickery will help get people up to speed quickly with the technology at the stage where we're trying to get other folks to do front-end screens for this or that nice-to-have configuration option. Also please do bear in mind that we don't have to do this with an actual *web server*. If you wanted to just take something like, say, Jef Poskanzer's embeddable web server and stick it into the side of Juliette, that might work too. We don't necessarily have to rely on the evil that is the CGI specification. Like I said, there's a lot of work going on in this area right now and many different tools are floating around. Tk 8.0 even has an httpd library that lets you define actions directly for "URLs", and it handles the callback whenever someone selects one of them. Everyone, and I mean everyone, is scrambling to produce HTML driven configuration utilities these days, and I really do think that the handwriting is on the wall here, Mike, in big, tall letters. ;) Besides, I think we're a lot more likely to find help if we go this route. I can think of someone right now who's already engaged in actively trying to do something all these lines under FreeBSD as a thesis project. Jordan From owner-freebsd-config Sun Jan 12 02:42:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id CAA20088 for config-outgoing; Sun, 12 Jan 1997 02:42:14 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id CAA20083 for ; Sun, 12 Jan 1997 02:42:10 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id CAA19781; Sun, 12 Jan 1997 02:42:03 -0800 (PST) cc: Michael Smith , config@freebsd.org Subject: Re: Config Manifesto comments? In-reply-to: Your message of "Sun, 12 Jan 1997 02:29:38 PST." <19576.853064978@time.cdrom.com> Date: Sun, 12 Jan 1997 02:42:03 -0800 Message-ID: <19777.853065723@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > actively trying to do something all these lines under FreeBSD as a ^^^along :-} From owner-freebsd-config Sun Jan 12 18:02:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA10842 for config-outgoing; Sun, 12 Jan 1997 18:02:17 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA10828 for ; Sun, 12 Jan 1997 18:02:13 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA13966; Mon, 13 Jan 1997 12:32:01 +1030 (CST) From: Michael Smith Message-Id: <199701130202.MAA13966@genesis.atrad.adelaide.edu.au> Subject: Re: Config Manifesto comments? In-Reply-To: <19576.853064978@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 12, 97 02:29:38 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 13 Jan 1997 12:32:01 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, config@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: . > > Well, I'm happy to be convinced otherwise, but I remain skeptical. If > > you can come up with something that can handle interactive activities, > > and asynchronously-posted server-side events without a client-side > > scripting language, then I'll happily go along with it. > > Well, define "interactive activities" please. :-) Naturally you're not Ok. There are two schools of interface-design thought that are relevant here. School One says : "make the interface pretty. present the user with lots of options, and when they hit OK, check all the answers and put up an error message about some of them." School Two says : "design your interface so that the user cannot enter erroneous data in the first place, insofar as 'erroneous' is an error that we can detect or are aware of." Anyone who's used a Microsoft product over the years will be familiar with School One. Apple software at its best is an example of School Two. HTML, by its very nature, restricts you to School One, except at the most anally restrictive end of the implementation scale, where you have sacrificed any attempt at integration and are basically asking questions one-by-one. Users usually start asking about desk lamps and rubber hoses at that level. > going to be able to do cute shaded draggy-bars and stuff in HTML, but > you can certainly do forms and menus which provide the same basic > functionality for the things you want to control (like filesystem > sizes), just not with quite so much flash. I can do without the flash > if it buys an easily distributed management station capability and > provides the closest thing to a "standard L&F" these days. 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. Your interface objects aren't bound to one another; I can't pick an item off a list, edit its details in some fields, then go on to another without swapping back and forth between several pages. That seems to defeat the whole point behind a graphical interface. It's got buttons and bitmaps, but it works like a pile of pieces of paper. Bad. There are lots of moderately nice things that you can do with Netscape or friends that aren't actually in-band with the HTML spec. Sure, if there was a decent browser with a sane license, I'd swallow my pride, learn its client-side scripting language and make it happen. But there isn't, and unless you've seen something at Usenix that us out here in the boonies haven't, I don't see it happening soon. > And doesn't server-push buy you a reasonable facsimile of async > server-side events? Just think of all those cameras. It's crude, but > it basically works. Er, yeah. So here I am with my gonzo web-based monitoring tool. I have a network of half a dozen machines that I'm watching. So I have six copies of my noncommercial web browser running. Great, eh? So, you say, have a single browser talk to a server that's collecting status from all the machines and summarising it. Yeah, you could put some stuff into a CGI script and have it talk... er, yeah, that sounds like a Romeo-substitute, just like he talked about in that manifesto thing. Meanwhile I have a tiny window on my screen with the names of my six machines, each is currently coloured green. One of them goes yellow, and a small alert pops up to tell me that the load average has just hit fifteen. Damn, someone is playing with PC-Emu again 8) > > Well that's just bloody wonderful, isn't it? I can just guess how > > well _that_ is going to be received. 8( > > Well, I'm going to make one last-ditch effort before giving in to that > most contemptible of fates, but naturally no guarantees on that. > They'll probably just blow me off. :( Tell them about their new employee that's doing a black port to Domain/OS. Only don't get him fired until he's finished it 8) > > The only thing that we win on using an HTML interface in this case is > > the ability to display on non-x-capable (Windows, Mac) systems. I > > Not *just* that, even when running locally it provides you with a > decoupled GUI interface, Argh! Here we go again. If you accept that a GUI interface is mandatory (eg. web browser), then I assert that Tk will do everything that you can do with HTML faster, in less memory, and with more independance. Hell, if people could swallow being stuck with Tcl for the client-side of things, we could find some win32-challenged contributors and make the client run under win32 and on the Mac as well. There aren't many platforms with a GUI web browser that Tcl/Tk won't run on (OS/2 is about the only one that comes to mind just now). > about, and you just let someone else sweat the browser (and there will > be new and interesting browsers coming out for some time to come), I'm sure there will. You can bet your (whatever) that they won't match our license expectations though, right? > whenever someone selects one of them. Everyone, and I mean everyone, > is scrambling to produce HTML driven configuration utilities these > days, and I really do think that the handwriting is on the wall here, > Mike, in big, tall letters. ;) This sounds like the lecture that the guys doing the 68k microcomputer architecture at IBM got around 1979. You can bet I like it about as much as they did. Regardless, as I've already said, if you can show me a good set of metaphors for the sorts of things I'm griping about I'll happily change my tune. My primary goal here is a working product, not a moral stance. > 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 [[ From owner-freebsd-config Sun Jan 12 22:42:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA22766 for config-outgoing; Sun, 12 Jan 1997 22:42:49 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA22761 for ; Sun, 12 Jan 1997 22:42:46 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id WAA15356; Sun, 12 Jan 1997 22:42:30 -0800 (PST) To: Michael Smith cc: config@freebsd.org Subject: Re: Config Manifesto comments? In-reply-to: Your message of "Mon, 13 Jan 1997 12:32:01 +1030." <199701130202.MAA13966@genesis.atrad.adelaide.edu.au> Date: Sun, 12 Jan 1997 22:42:29 -0800 Message-ID: <15352.853137749@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Ok. There are two schools of interface-design thought that are relevant > here. > > School One says : "make the interface pretty. present the user with lots > of options, and when they hit OK, check all the answers and put up an > error message about some of them." > > School Two says : "design your interface so that the user cannot enter > erroneous data in the first place, insofar as 'erroneous' is an error > that we can detect or are aware of." Right. And, unfortunately, there are also very few people around who are implementing UIs from the 2nd school these days - not even us (just look at most of sysinstall's "forms"). It's just harder, as a general rule, to provide frameworks which do on-the-fly validation of user input. It's not impossible, and I've written forms packages which provided for both, it's just harder. As you say, I'm not here to argue principles or fundamental questions of moral rectitude - there are dozens of ways to skin a cat and all of 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! :-) > HTML, by its very nature, restricts you to School One, except at the > most anally restrictive end of the implementation scale, where you > have sacrificed any attempt at integration and are basically asking > questions one-by-one. I don't buy that. I think of it as more akin to a hypercard stack. Annoyingly page-based, often stupidly organized, but you can still cluster things by concept. My top networking page is going to have a list of all my networking service types, with pointers to other documentation at the bottom (HTML *does* allow you to do a nice job of integrating your relevant documentation with the actual installation procedures, if you plan for that in advance and Do It Right). I click on, say, DNS Services and I get a sub-page allowing me to add, delete, query or change entries, or maybe just figure out what DNS is at all and why I'd want to set it up (links to tutorials and such). 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, what's more, Juliette would have to know about the documentation properties for each UI screen or you could never keep them properly associated when changes were made. I dunno, HTML just sounds a lot easier to me! :-) > 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? I'm willing to look at all this as pie-in-the-sky material if no browser exists which provides the features we absolutely *must gotta have*, but I'm having a hard time believing that nothing truly exists. > There are lots of moderately nice things that you can do with Netscape > or friends that aren't actually in-band with the HTML spec. Sure, if > there was a decent browser with a sane license, I'd swallow my pride, > learn its client-side scripting language and make it happen. But there 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." > Er, yeah. So here I am with my gonzo web-based monitoring tool. I have > a network of half a dozen machines that I'm watching. So I have six > copies of my noncommercial web browser running. Great, eh? 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. If frames become the way to go for something non-essential to the installation, what do I care? If you want to use all the fancier features of this tool, I think that a fully-featured browser would be a reasonable prerequisite - just so long as none of the very lowest level ``get the bits on the disk'' pages use such features. With frames and java support as prerequisite features, you can then visit your cute SNMP replacement page and rock out. If you don't have a decent browser, you don't visit that page, sorry. Get a better browser and come back. > So, you say, have a single browser talk to a server that's collecting > status from all the machines and summarising it. Yeah, you could put No, I didn't actually say that. That would be gross. :-) > Argh! Here we go again. If you accept that a GUI interface is mandatory > (eg. web browser), then I assert that Tk will do everything that you can > do with HTML faster, in less memory, and with more independance. Well, I'm certainly willing to be so wowed by your Tk-based prototype 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! :-) > Hell, if people could swallow being stuck with Tcl for the client-side > of things, we could find some win32-challenged contributors and make the > client run under win32 and on the Mac as well. There aren't many > platforms with a GUI web browser that Tcl/Tk won't run on (OS/2 is about > the only one that comes to mind just now). Hell, I don't *dislike* this idea, Mike. You know I'm a big fan of Tcl and Tk, and I'm just playing with Tk8.0 right now to see what kinds of neat new features it has. The idea of a Tk based client application using a socket to talk to some nifty configuration server running on your FreeBSD box scarcely fills me with horror, and it sounds like a very clean way of solving the problem. I'm just afraid that like all clever, custom solutions, people will have difficulty in understanding it and we'll end up with maybe 2 or 3 people working on the code. :-( 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 properties will Juliette try to support in the first version, and how will Romeo determine the composition of its various configuration screens? Will Juliette feed Romeo raw Tk code representing the interface to be created, or what exactly? 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? I'm willing to dive in and help you code this, heck, I just want to know where you're going first! :-) 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. :-) > 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. > Regardless, as I've already said, if you can show me a good set of > metaphors for the sorts of things I'm griping about I'll happily > change my tune. My primary goal here is a working product, not a Well, I'm still not really sure just what it is you *are* griping about, so it makes any sort of rebuttal rather difficult to formulate. :-) 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? Jordan From owner-freebsd-config Mon Jan 13 00:06:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA26918 for config-outgoing; Mon, 13 Jan 1997 00:06:40 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA26908 for ; Mon, 13 Jan 1997 00:06:36 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id SAA16651; Mon, 13 Jan 1997 18:36:27 +1030 (CST) From: Michael Smith Message-Id: <199701130806.SAA16651@genesis.atrad.adelaide.edu.au> Subject: Re: Config Manifesto comments? In-Reply-To: <15352.853137749@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 12, 97 10:42:29 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 13 Jan 1997 18:36:26 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, config@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 [[ From owner-freebsd-config Mon Jan 13 12:30:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA03542 for config-outgoing; Mon, 13 Jan 1997 12:30:41 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA03536 for ; Mon, 13 Jan 1997 12:30:37 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vjsyx-0005Bj-00; Mon, 13 Jan 1997 13:27:47 -0700 To: "Jordan K. Hubbard" Subject: Re: Config Manifesto comments? Cc: Michael Smith , config@freebsd.org In-reply-to: Your message of "Sun, 12 Jan 1997 22:42:29 PST." <15352.853137749@time.cdrom.com> References: <15352.853137749@time.cdrom.com> Date: Mon, 13 Jan 1997 13:27:47 -0700 From: Warner Losh Message-Id: Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <15352.853137749@time.cdrom.com> "Jordan K. Hubbard" writes: : Right. And, unfortunately, there are also very few people around who : are implementing UIs from the 2nd school these days - not even us : (just look at most of sysinstall's "forms"). It's just harder, as a : general rule, to provide frameworks which do on-the-fly validation of : user input. It's not impossible, and I've written forms packages : which provided for both, it's just harder. javascript and/or java should be able to bridge this gap for the most part. You can easily do validation, have some fields affact other fields, etc. Java isn't a bad language when progamming in the small. : > HTML, by its very nature, restricts you to School One, except at the : > most anally restrictive end of the implementation scale, where you : > have sacrificed any attempt at integration and are basically asking : > questions one-by-one. : : I don't buy that. I think of it as more akin to a hypercard stack. : Annoyingly page-based, often stupidly organized, but you can still : cluster things by concept. My top networking page is going to have a : list of all my networking service types, with pointers to other : documentation at the bottom (HTML *does* allow you to do a nice job of : integrating your relevant documentation with the actual installation : procedures, if you plan for that in advance and Do It Right). I click : on, say, DNS Services and I get a sub-page allowing me to add, delete, : query or change entries, or maybe just figure out what DNS is at all : and why I'd want to set it up (links to tutorials and such). Yes. Adding java to the mix would also give you the power of the markup language HTML (which can do a lot of things right) with the ability to do basic, nice UI things as well. Not perfect, mind you, but better than just raw HTML. Of course you do lose the ability to do this from non-java enabled browers (unless you also validate stuff on the server side). : 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. :-) :-). : 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? I'd like to see the system be able to do the following things. I have opinions on HOW they should be done, but I'll leave it and focus on WHAT: 1) Anything that can currently be done with sysconfig should be handled. Interfaces, running/not running certain daemons, etc etc. 2) All DNS magic should be done for a DNS client (a server would be harder, but doable). 3) Add/delete/flambe users, groups 4) Handle adding/removing new hardware to the system, including disks. This may require the ability to rewrite config files and rebuild a kernel. 5) NFS setup and configuration 6) Add and delete new interfaces and/or new dialup connections. 7) Configure modems and/or getty for dialin, dialout and hardwired lines. And likely a lot of other stuff that isn't leaping to my brain at the moment. Warner From owner-freebsd-config Mon Jan 13 20:08:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA01262 for config-outgoing; Mon, 13 Jan 1997 20:08:07 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA01257 for ; Mon, 13 Jan 1997 20:08:04 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id UAA21473; Mon, 13 Jan 1997 20:03:10 -0800 (PST) To: Michael Smith cc: config@freebsd.org Subject: Re: Config Manifesto comments? In-reply-to: Your message of "Mon, 13 Jan 1997 18:36:26 +1030." <199701130806.SAA16651@genesis.atrad.adelaide.edu.au> Date: Mon, 13 Jan 1997 20:03:10 -0800 Message-ID: <21469.853214590@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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 From owner-freebsd-config Mon Jan 13 21:44:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA23341 for config-outgoing; Mon, 13 Jan 1997 21:44:09 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA23298 for ; Mon, 13 Jan 1997 21:44:01 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id QAA23535; Tue, 14 Jan 1997 16:11:00 +1030 (CST) From: Michael Smith Message-Id: <199701140541.QAA23535@genesis.atrad.adelaide.edu.au> Subject: Re: Config Manifesto comments? In-Reply-To: <21469.853214590@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 13, 97 08:03:10 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 14 Jan 1997 16:10:59 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, config@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: ... > 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. I was planning on having Juliet support downloading of new/updated server-side modules. I'm aware that if we attempt to keep up with the shifting sands that are FreeBSD at any second, we'll lose. > 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. Fair enough. "Everything is data". This of course assumes that there will be only one frontend to Juliet, or that Juliet will have to know about all the frontends that require meta-configuration information. I'm not sure yet whether that counts as Bad, or whether you're going to suggest that all frontends should use the same meta-config information. Tricky. 8) > 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 This takes you back to the original problem to some degree, in that the client and server need to be matched. I can't see that as being such an unreasonable requirement though; it'd be murder trying to be too general. If we want to talk vanilla HTML though, we need to look at something more abstract, as the http server will need to turn it into HTML and interact with the browser. > 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. :-) Conceded. Although it may turn several brains to mush in the process 8) > To me, that means coming up with a meta-markup language which allows: Ok; that's basically the reverse of my "embedded code in HTML" idea. So does anyone have any good ideas here? I know a grand total of Nothing about markup languages, so I'm not sure I'm the monkey for this job. > o Embedded HTML, for when "ya just gotta." > o A representation of variables, both read-only and read/write. For now, I think it would be reasonable to come up with some basic contexts for variables, eg. where the 'entry' context means "user enters some value", 'pick' means "pick one of these", etc. Provided there was a small set of lowest-common-denominator contexts that one could fall back to, one could specify a 'better' context and know that for an inferior browser the HTML generator would fall back. All this is fine on the micro scale; I don't know how well it would scale though. > o A representation of inline function calls and the data type > the return. Aha. > o The specification of field-validators for any embedded variables > in the page. That's a special case of the previous one. > o The URL of a help screen (so we can construct standard "Help > buttons") for all pages. Hmm; do you want to do that by convention rather than stipulation? Still, the basic idea is valid. > >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. Urk. That's where the statelessness bites me. How long do you keep all this generated state around? Or do you regenerate it when the response comes back? > > 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! :-) Hah! I knew you had doubts, I just had to find them 8) Seriously, the more I look at the concept of the stateless interaction, the more it scares me. > 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. Natch. Although you could hide "installation" under "common tasks" 8) I just wanted to make sure I was talking at the same target that everyone else was, so that I can get some basic 'shape' feel. > 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. Given your protestations, let's go with HTML-only for now, and see where that leaves us in a while. Could some members of the local HTML literati perhaps give us some idea of the basic data-editing constructs that you can expect from a simple-minded browser like Lynx or Chimera? >From these, it should be possible to get some idea of how compound editing pages can be constructed, and thus what sort of backending is required to make them run. > 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 [[ From owner-freebsd-config Wed Jan 15 04:23:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA24608 for config-outgoing; Wed, 15 Jan 1997 04:23:36 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA24603 for ; Wed, 15 Jan 1997 04:23:34 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id EAA12819; Wed, 15 Jan 1997 04:23:22 -0800 (PST) To: Michael Smith cc: config@freebsd.org Subject: Re: Config Manifesto comments? In-reply-to: Your message of "Tue, 14 Jan 1997 16:10:59 +1030." <199701140541.QAA23535@genesis.atrad.adelaide.edu.au> Date: Wed, 15 Jan 1997 04:23:22 -0800 Message-ID: <12815.853331002@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Fair enough. "Everything is data". This of course assumes that there > will be only one frontend to Juliet, or that Juliet will have to know > about all the frontends that require meta-configuration information. I look at it more this way: Juliet is just a network peg board. If you ask it for a named property in a certain part of the name space, you either get it or you don't. The name space allows you to group things together in related categories, and if some weird 3D front end of the future wants to register a set of .VRML properties for each screen, well, more power to it - the other front-ends don't need to care because they don't look for those properties. :-) > I'm not sure yet whether that counts as Bad, or whether you're going to > suggest that all frontends should use the same meta-config information. No, simply that we organize the property name space properly so that all frontends don't ask for the meta-config information under the same heading if they have different needs. > This takes you back to the original problem to some degree, in that > the client and server need to be matched. I can't see that as being > such an unreasonable requirement though; it'd be murder trying to be > too general. I think a TCL engine in both sides is a reasonable architectural decision (even if Juliet were to end up just speaking HTTP). It's just too handy not to have it. :) > Ok; that's basically the reverse of my "embedded code in HTML" idea. So > does anyone have any good ideas here? I know a grand total of Nothing > about markup languages, so I'm not sure I'm the monkey for this job. > > For now, I think it would be reasonable to come up with some basic > contexts for variables, eg. > > > That or we could go to a model where each page was just raw TCL, and from that TCL you could generate on-the-fly HTML using various commands for the purpose. As you navigate, you just jump from one TCL file to another. > Hah! I knew you had doubts, I just had to find them 8) Seriously, the > more I look at the concept of the stateless interaction, the more it > scares me. I'm working on a proof-of-concept implementation now. I'm not going to be sure what the limitations of the model are until I try it, I've decided. :-) > Given your protestations, let's go with HTML-only for now, and see where > that leaves us in a while. Could some members of the local HTML literati > perhaps give us some idea of the basic data-editing constructs that > you can expect from a simple-minded browser like Lynx or Chimera? Yes, I wouldn't mind this either. Anyone?! :-) Jordan