Date: Wed, 15 Jan 1997 04:23:22 -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: <12815.853331002@time.cdrom.com> In-Reply-To: Your message of "Tue, 14 Jan 1997 16:10:59 %2B1030." <199701140541.QAA23535@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. > > <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"> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12815.853331002>