Date: Wed, 19 Jun 1996 15:17:02 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rjk@sparcmill.grauel.com (Richard J Kuhns) Cc: terry@lambert.org, current@FreeBSD.org Subject: Re: tcl -- what's going on here. Message-ID: <199606192217.PAA14306@phaeton.artisoft.com> In-Reply-To: <199606191924.OAA26670@sparcmill.grauel.com> from "Richard J Kuhns" at Jun 19, 96 02:24:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606192217.PAA14306>