Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!cfctech!teemc!ka3ovk!drilex!dricejb From: dricejb@drilex.UUCP (Craig Jackson drilex1) Newsgroups: comp.sys.mac.programmer Subject: Re: Communications Toolbox questions Message-ID: <6708@drilex.UUCP> Date: 8 Dec 89 00:39:46 GMT References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <37000@apple.Apple.COM> <6576@drilex.UUCP> <37066@apple.Apple.COM> Reply-To: dricejb@drilex.UUCP (Craig Jackson drilex1) Organization: DRI/McGraw-Hill, Lexington, MA Lines: 66 In article <37066@apple.Apple.COM> jdevoto@Apple.COM (Jeanne A. E. DeVoto) writes: >In article <6576@drilex.UUCP> dricejb@drilex.UUCP (Me) writes: >>It seems that the CommToolBox designers are expecting developers of >>existing scripting languages to do violence to their previous product >>appearance by exposing the configuration strings to the script-writer. >>It is far more likely that developers of such products will hard-code >>knowledge of the configuration strings used in the sample tools, so that >>the program can retain its previous interface. Possibly, they may expose >>the config strings in an 'Advanced User' interface. If they do not, the >>variety of the useful CommToolBox tools will be diminished. > >I don't see any reason why developers need hard-code specific strings for >scripting languages. Suppose the existing syntax for setting a terminal >parameter such as font size is "set terminal parameter fontSize to 9". >To set this parameter using the CTB, the script interpreter would use >TMSetConfig (because you are setting a terminal parameter) with the string >"fontSize 9". This can be done, clearly, without the interpreter having >any specific knowledge of the terminal parameters or their legal values. >The *user* will need to know the parameters and values for that tool, but >this information should be included in the tool documentation itself. > >The above configuration will return an error, by the way, since the basic >terminal tools use "size" rather than "fontSize" as a parameter name. Since >the character position of the bad token is returned, the script interpreter >can check the string it sent against the position returned to see whether >the problem is a bad parameter or bad value, and post an appropriate user >error, e.g. "FontSize is not a valid parameter for the TTY terminal." >Again, no special knowledge is needed by the interpreter in this example. Except that the users of that product probably don't care whether the programmer used the toolbox or did it himself; they just want it to work. And they don't want to re-write their 2000 lines of scripts just to be compatible with the new release. So if the script language already had a command 'baudrate 2400', that still has to work. Therefore, the language implementor must know to translate that to 'baud 2400' if he/she is using the toolbox. What you seem to be saying is that the tools of the CommToolBox are designed to be apparent to their end-users. That's fine, but if that is true, it will greatly lengthen the time for acceptance. For most existing communications packages, the CommToolBox will be a new submode on the side; the existing stuff will be needed, and need to be there under the same syntax. To have avoided this problem, the CommToolBox would have to have shipped around the time of the original Mac 512K.... >>Because of existing scripting languages, standardization of configuration >>strings will occur. Wouldn't it be wiser, and more Apple-like as well, >>to offer some guidelines as to their contents? > >Guidelines for recommended parameter and value names will be forthcoming >from DTS sometime soon (most likely as a technote). Fine. I'll be looking for them. BTW, shouldn't somebody tell APDA that this isn't really a Class 1 product yet? Sure looks beta-ish to me.... >-- >====== jeanne a. e. devoto ======================================== > jdevoto@apple.com | You may not distribute this article under a > jdevoto@well.UUCP | compilation copyright without my permission. -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}