Date: Tue, 14 Jan 1997 16:10:59 +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: <199701140541.QAA23535@genesis.atrad.adelaide.edu.au> In-Reply-To: <21469.853214590@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 13, 97 08:03:10 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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. <var name=rate mode=rw context=entry comment="Rate of frustration"> <var name=divisor mode=rw context=pick(1 2 5 10) comment="Caffeine divisor"> 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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701140541.QAA23535>