From owner-freebsd-current Wed Jun 19 15:19:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA29141 for current-outgoing; Wed, 19 Jun 1996 15:19:34 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA29134 for ; Wed, 19 Jun 1996 15:19:23 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA14306; Wed, 19 Jun 1996 15:17:02 -0700 From: Terry Lambert Message-Id: <199606192217.PAA14306@phaeton.artisoft.com> Subject: Re: tcl -- what's going on here. To: rjk@sparcmill.grauel.com (Richard J Kuhns) Date: Wed, 19 Jun 1996 15:17:02 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.org In-Reply-To: <199606191924.OAA26670@sparcmill.grauel.com> from "Richard J Kuhns" at Jun 19, 96 02:24:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > TCL uses a tool encapsulation model, requiring TCL changes to match > > corresponding tool changes when they occur to the embedded tool. This > > is grossly inefficient and unmodular. > > Either I'm having trouble parsing this paragraph, or you're thinking about > using tcl differently than I am. > > Assume a library that provides a low-level service -- libdisk.a, for > example. For the tcl interface, I'd write some C code that defines a tcl > object (maybe called a `Disk') that responds to some more-or-less generic > set of messages ("format", "describe_boot_block", etc). A properly > designed (buzz-word alert!) object-oriented interface would present a > consistent view of the higher-level Disk tool to any tcl code, insulating > the tcl code from changes to the lower-level libdisk tool. > > ... And then you build a script, which is throw away code, which encapsulates the order of operation for these objects and their preferred interactions in order to define a system interface. My problem is with the enabling act of building the script to be sufficient as providing the sole system interface for a given set of objects. The "adduser" example is a good case in point. Another would be the partition management and disklabel management (which if we design honestly, are instances of the same operation with gratuitiously different interfaces... an attempt to make it hard for the users? No: an expediency permitted [*encouraged*] by the software that controls their interactions.). > > I believe "throw away code" should not be encouraged in > > the source tree. > > I fully agree; just don't throw out the baby (easier/faster development) > with the bathwater. I agree with not throwing out the baby... which is why you put it in ports, so people can use it for rapid prototyping or site-specific administrative tasks, with no danger of those scripts creeping into the source tree. My problem with it being a system component is that it is acceptable to build other system components from it if it is guaranteed to exist. Look at the mess we have with the /etc/rc* files not being data driven; it's wrong to think that hacking an rc file to set system data can be an acceptable way of solving a configuration-change problem. The main obstacle to updating the system is the data is embedded in scripting in the /etc directory. The main obstacle to templating diskless/dataless systems from a single update template ("just reboot after the server is updated") is data embedded in scripting in the "/etc" directory imported by the client. The main obstacle to changing system policy templates for use in the creation of new users, given a TCL or PERL script-based "adduser", would be the policy data embedded in the TCL/PERL script. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.