Xref: utzoo comp.sys.mac:40750 comp.sys.mac.programmer:9898 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!well!svc From: svc@well.UUCP (Leonard Rosenthol) Newsgroups: comp.sys.mac,comp.sys.mac.programmer Subject: CommToolbox & CommPrograms (was Re: 11 New Features) Summary: We would if we could... Message-ID: <14238@well.UUCP> Date: 23 Oct 89 16:00:02 GMT References: <969@bridge2.ESD.3Com.COM> <25744@santra.UUCP> <974@bridge2.ESD.3Com.COM> <14138@well.UUCP> <979@bridge2.ESD.3Com.COM> <25791@santra.UUCP> <8769@hoptoad.uucp> Reply-To: svc@well.UUCP (Leonard Rosenthol) Organization: Whole Earth 'Lectronic Link, Sausalito, CA Lines: 43 I would like to put my two cents into the CTB vs. Comm Programs discussion. For many months now the commercial communications developers have been discussion amongst ourselves (yes, I do talk to my competitors :-) about the merits and demerits(??) of the CTB and the general consencous is that the CTB is, of course, a good thing both for us and for our users. It will make it easier for us to add new emulators and protocols as well as provide connections we may not even have thought possible - HOWEVER it is certainly not the end all and is FAR from perfect for many of us. The biggest problem with doing development for it now and probably the biggest reason that WK11 and MPII3.0 do not support it is that IT IS NOT AVAILABLE TO THE PUBLIC! It would certainly not be a good marketing practice to develop a product using someone else's technology and then have to hold the product until the other product ships...Once the CTB becomes avail, will you start to see versions of commercial comm products that use it - sure - but who, what. when, etc. is anybody's guess. There are also some serious limitiations of the CTB for many developers that have not been mentioned before and have even been glossed over. Among them are the inability to properly integrate with a scripting/macro language. There is not way when supporting the CTB to say something like 'Set Terminal Parameter Columns to 80'. The only way to set the parameters of a tool is either via a dialog (no good during automatic scripting!) or via a config string which is specific to the tool - if the tool changes then the string changes and the and command will fail - but the script relies on that settings.... Another problem has to do with graphics terminals - contrary to the docs in the CTB stuff, you can not fully implement support for most/all graphics terminals. Go ahead - try doing a Tek 4014, for example.... Also the question comes up as to how ana pplication with a scripting language interacts with a graphics terminal...Can/Should you be able to do something like 'When Pixel is Green.. or Wait till Square is 10x10?' Or am I out in left field on this one? I personally have nothing against the CTB, I think it is an excellent idea and it is very much like things other have devised like Juri, myself, etc. I am hoping that future versions will solved some of the above problems (and others not mentioned) but for a first release I think they did a very good job -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025