The momentous news this week is that Frontier, previously an expensive scripting program that’s in many ways better than AppleScript, is now free. Tonya passes on advice for those writing ReadMe files, Adam muses briefly about a good use for some of the PowerTalk technology, and we look briefly at the BBEdit 3.1.1 update. Finally, we have MailBITS about RAM Doubler, PC Setup 1.0.6, and the Communications Decency Act.
This issue is a touch late partly due to the Memorial Day holiday in the U.S., and partly due to us helping Chad and Galen Magendanz ShrinkWrap their apartment and mount the resulting disk image in their new house. Apologies for any confusion our tardiness might have caused. [ACE]
Updated Updater — Last week Connectix released a maintenance fix for the RAM Doubler 1.5.2 update reported in TidBITS-278. Although the fix is called Updater 1.5.2a, it’s important to note the fix is for the Updater application rather than RAM Doubler itself. The current version of RAM Doubler remains at 1.5.2, and if you’ve updated to 1.5.2 successfully, you don’t need this updater.
The only difference between Updaters 1.5.2 and 1.5.2a is that the memory allocation for the application has been increased from 384K to 512K. Some machines without RAM Doubler would erroneously report a corrupted master disk when the original Updater ran. If you encountered this problem, you can grab the new Updater application, or work around the problem by increasing the Updater’s memory allocation in its Get Info window. [GD]
Decency’s in the Eye of the Beholder — An alternative to the Communications Decency Act of 1995 (see TidBITS-263) has been proposed by Senator Patrick Leahy. The Leahy bill, S.714 (called the "Child Protection, User Empowerment, and Free Expression in Interactive Media Study" bill) proposes a five month study of current law and technological capabilities surrounding access to controversial content via electronic media. At this time, this bill presents the only alternative to the Exon/Gorton Communications Decency Act, which is likely to pass without a strong show of support for Leahy’s alternative. More information and, yes, an online petition can be found at the following URLs. It’s worth noting that the original petition against the Communications Decency Act gathered more than 108,000 signatures. [GD]
PC Setup 1.0.6 Yanked — Apple pulled version 1.0.6 of PC Setup from distribution last week due to "several" unspecified problems. If you’re running PC Setup 1.0.6, Apple recommends to switch back to the correct version of PC Setup for your machine. If you’ve got a DOS Compatible 6100 system, you’ll want to use PC Setup 1.0.3; for 630 and 640 DOS Compatible machines, use PC Setup 1.0.5. Watch out: these are big archives (2.6 MB and 1.3 MB respectively), and they have those funky ultra-long Apple URLs: [GD]
I’ll point out, as I did to those present at the awards ceremony at WWDC, that all of this year’s winners are from outside the U.S. This adds some substance to Apple’s claim that the Macintosh is a growing force in global computing.
Bare Bones Software recently updated the commercial version of its popular text editor BBEdit to version 3.1.1 (see TidBITS-202 for a dated review of BBEdit). The new version has only a few improvements over those in earlier 3.x versions, but the nature of the improvements shows that Bare Bones Software constantly seeks to improve BBEdit.
In TidBITS-276, Adam wrote about Internet Config, an important Internet utility by Peter Lewis and Quinn that helps centralize your basic Internet information so other IC-savvy applications can automatically find it. Given that BBEdit is popular for HTML authoring (and is bundled with Apple’s new Internet Servers), and given the popularity of the Internet among Macintosh users, it’s great to see BBEdit now sporting an optional Internet menu that enables you to switch quickly to your designated Internet clients, including your news reader, email client, FTP client, Web browser, and Telnet client. You can also Command-click a URL that appears in a BBEdit document to launch or switch to the appropriate helper application and go to the resource specified in the URL. The Internet menu also enables you to view the current document in your designated Web browser, a feature that HTML authors may find handy.
BBEdit 3.1.1 also now works with Kodex, a utility that helps programmers print source code files with special formatting options. BBEdit also supports the QuickDraw GX printing architecture.
A demo version of BBEdit 3.1.1 is available, and it lets you to try all the new features, but you cannot Save, Save As, or Export, and printed output has a demo watermark.
You can also try BBEdit Lite, a lightweight, freeware version of BBEdit, though you won’t see any of the new features in action.
Although BBEdit Lite is a credible product in its own right, if you’re considering purchasing the $119 commercial version, check out BBEdit’s pricing information file. Why? Because almost everyone should fit into one of their discount options, and the discounts are often substantial. Bare Bones Software also recently set up a deal with Baseline Publishing, where Baseline is offering users of Vantage (Baseline’s text editor) a $69 upgrade to BBEdit.
BBEdit now comes on a nicely done CD-ROM, complete with online documentation, twenty or so contributed extensions (plug-in type modules that extend BBEdit’s capabilities), and a number of additional goodies. If you don’t have a CD-ROM drive or find that you want a printed manual, a disk-manual set is available for an additional $15 plus shipping and handling.
I’m no fan of PowerTalk, but I’ve found the perfect use for part of the PowerTalk technology that could not only make the Web easier to use but could also give the Macintosh a notable advantage over other platforms. Basically, we need the PowerTalk Key Chain.
Why the PowerTalk Key Chain? After all, isn’t it supposed to simplify the process of remembering usernames and passwords for AppleShare servers? Yes, and from what I hear from PowerTalk users in large organizations with hundreds of servers, the Key Chain is a necessary fact of life. No one can remember all those different usernames and passwords, especially if the passwords change frequently.
The reason I think the PowerTalk Key Chain could prove useful on the Web is that more and more sites now require authentication before they allow you to access the good stuff. This makes sense in the case of a site like InfoSeek – where you pay for an account to search commercial publications and databases – but is increasingly irritating in the case of a publication like HotWired, where it seems that they mostly want to know that you were there.
I have no idea how feasible this is for the developers of the Macintosh Web browsers to implement, but just imagine how much easier it would be to use these authenticated sites if, the first time you hit one in a session, you could enter your PowerTalk Key Chain password to get in. Then, all subsequent authentication requests from Web servers would use the appropriate username and password from your Key Chain.
I currently have nine separate usernames and passwords to track for different services on the Web, and although that’s not a lot, it adds up fast when I add in the usernames and passwords for all my accounts on the commercial online services, Unix machines, Timbuktu Pro accounts, and so on. Since all of these accounts have different security requirements, I can’t even use the same set of passwords, much less the same single password (and to do so would be a major security mistake anyway). Worse, since some of these Web services enable you to pick your userid and others require your email address or something similar, I don’t have even have the same username for all of them. It’s out of control and it’ll only get worse.
The PowerTalk Key Chain could end to this mess, at least for Macintosh users. And, the Web browser that first implemented support for the PowerTalk Key Chain could gain a significant feature advantage over the rest, particularly for folks who use authenticated Web sites frequently. Of course, one major problem with this scenario is that PowerTalk hasn’t been widely accepted (for generally good reasons), which doesn’t endear developers to the idea of supporting it heavily.
When I asked several Macintosh Web developers about this possibility, the problem mentioned above was foremost for Netscape, which is considering automating the process, but not through PowerTalk. The NCSA Mosaic developers reportedly plan to address the problem by supporting a modular security framework being developed by Spyglass, the company that handles Enhanced Mosaic.
So, in the end, the PowerTalk Key Chain may not turn out to be the solution. But it may serve as the pointer to a solution since it does today for AppleShare servers what we can only hope becomes possible tomorrow for authenticated Web sites.
Lately I’ve spent a lot of time sorting through shareware and freeware utilities for a number of projects, trying to find basic facts for each utility, such as what the utility does, who wrote it (first and last name), how I should pay if I like it, and how I can reach the author by email. Surprisingly, these facts are often omitted, tucked away in odd places, or poorly explained. So, here’s some complaining and some advice for ReadMe file writers.
Make an Elevator Statement — I once read an excellent book called "The High Tech Marketing Companion," by Dee Kiamy (Addison-Wesley. ISBN 0-201-62666-7), which suggests that every product needs an elevator statement. An elevator statement conveys what a product is and what’s cool about it, in the time it takes to ride an elevator from the lobby to the top floor of an office building. The idea is that you may only have that much time to explain your product to a venture capitalist riding the elevator with you. Whether or not you’re bucking for venture capital, every utility’s ReadMe file should have such an elevator statement, along with the price of the software, the name of the author, and the author’s contact information.
Make it Open — ReadMe files are often set up as SimpleText read-only documents, so you cannot copy text from them. This makes it more difficult to be certain you get email addresses, names, and so on correct, should you be attempting to review the software or drop an author a note in email. In addition, if you want to copy the author’s snail mail address to send in your shareware payment, such read-only documents get in the way even more. Read-only documents are used to prevent people from changing them, but I don’t think this is a significant concern.
Make it Legible — My final bone to pick concerns legibility. Many authors format ReadMe file text in a tiny size with no white space between paragraphs. Some authors assume I’m going to print out the ReadMe: a poor assumption, since until I can figure out what the application does, I’m unlikely to turn on my printer, and in general, I don’t print, and nor should I, given that the documentation already exists online where I can file it neatly with the application.
If you create a ReadMe file, please consider the people who will read it. Make the characters large enough to be legible, accommodate people who want to read it online, explain what your product does and who you are, and remember that the quality of your ReadMe may influence not only how many people use your product, but also how many people figure out how to send you friendly messages, registration forms, chocolates, site license fees, and so on. If you’ve got a great application, be it freeware or shareware, don’t saddle it with a lousy ReadMe.
As for back as November of 1992 (see TidBITS-153 and TidBITS-154), TidBITS has been talking about Frontier, UserLand Software’s system-level scripting environment for the Mac. It’s commonly described as "AppleScript on steroids," or "AppleScript done right," but neither summary does it justice. Frontier is an OSA-compliant scripting system with a number of unique features that (in most cases) make it both more powerful and more robust than AppleScript. Frontier has also been around longer than AppleScript: Frontier was a real, working, shipping product when AppleScript was only much-touted vaporware from Apple.
If Frontier has a longer track record and offers more power, why doesn’t everyone using Frontier instead of AppleScript? There are a number of reasons. First, Frontier’s knowledge requirement: whereas QuicKeys and HyperTalk are relatively accessible to sophisticated Macintosh users, UserTalk (Frontier’s scripting language) isn’t for the faint of heart: essentially, in-depth use of Frontier requires some programming experience. Second, AppleScript: these days, Apple’s own scripting system ships with System 7.5 and is widely available in other channels. Why bother with Frontier – even if it offers more power – when a "reasonable" solution is already on hand and supported by Apple? Third, until recently, Frontier had a price tag attached: to develop custom solutions using Frontier, it usually cost you over $200 to get in the game. Although Frontier was a powerful package with a devoted group of users (and Frontier Runtime made distributing Frontier scripts easier), clearly the "adoption threshold" for Frontier limited its audience.
So, Dave Winer and the folks at UserLand decided to eliminate reason number three: With release 4.0 – code named Aretha – Frontier will be available for free. And what’s more, the new Frontier is setting its sights on the Internet and online publishing. The first public beta of Aretha is available on UserLand’s Web site at HotWired; expect more betas (and more net-specific features) in the coming weeks:
In short: if you run a Macintosh-based Web server or need to extract custom capabilities from your Internet applications, Aretha might rock your world.
The Object Database — On the surface, Aretha is not much different from the currently-shipping version of Frontier. (In fact, the core application and kernel of Aretha is identical to Frontier 3.0.3.) What’s changed, then? One of Frontier’s unique (and most useful) features is called the Object Database. Basically, the Object Database is a hierarchical, disk-based storage system for handling objects Frontier knows about. Those objects can be data (strings, outlines, a chunk of word-processing text, a menubar, raw binary data, and so on), and they can be scripts. These objects are stored in tables, and (of course) tables can contain still more tables, so objects can be organized in whatever manner most meets your needs. Because Frontier is OSA-compliant, the Object Database can store and manage scripts in UserTalk as well as other OSA languages you might have installed (such as AppleScript, QuicKeys, or – keep your fingers crossed! – MacPerl).
The power behind the Object Database is simple: everything is stored in one place, it’s persistent between Frontier sessions, and it’s much faster than storing all these objects as separate files in the Finder. This lets your scripts communicate with each other and share information very easily; it also encourages you to leverage work from other scripts and solve problems in small, reusable chunks. In fact, one of the neatest things about the Object Database is that UserLand ships it with a bunch of useful scripts already installed: these not only serve as examples of how to write Frontier scripts, but also how to re-use code.
Scripting the Net — Though the Frontier application may be the same as in the previous release, the Object Database in Aretha contains a number of scripts and utilities specific to using Frontier in conjunction with Internet applications like Netscape, Eudora, Anarchie, and WebSTAR (formerly known as MacHTTP). In future betas, you can expect these built-in utilities to expand considerably. You may be thinking that all these applications can be tied together with AppleScript, and you’re right. But it’s only in observing the power and utility Frontier brings to the equation that you start to understand what UserLand is thinking. For example:
- WebWorm: The idea of a writing a worm for the World-Wide Web is not a new one (and it’s not insidious – what do you think WebCrawler and Lycos are at heart?). The basic idea is this: point the worm at a Web page and it follows and catalogs every link it finds, essentially recording a tree of everywhere that particular page leads. The Web is too big and changes too fast for it to be fully cataloged by worms, but that doesn’t mean they aren’t useful utilities. I tried to write a Web worm using AppleScript a few months ago: let’s just say I met with mixed success. Aretha has a basic Web worm built in that works in conjunction with Netscape 1.1N.
- CGI Scripts: CGI stands for Common Gateway Interface, and it lets a Web server execute custom commands based on user input (for instance, via a form or a button on a Web page). The programs the server executes are called CGI scripts. On a Unix system, they’re often written in Perl (a language with strong text-handling capabilities). On the Mac, WebSTAR (and MacHTTP) support CGIs via AppleScript. Starting with beta 1 of Aretha, WebSTAR can have Frontier handle its CGIs. This doesn’t mean rewriting any AppleScript CGI’s you’re already using – after all, Frontier handles AppleScript just fine. But using Frontier gives you more speed and flexibility, and (perhaps most importantly), you can use the Object Database to store information for your scripts.
- AutoWeb: The first beta of Aretha focuses almost exclusively on WebSTAR, but as future versions of Aretha tie directly into more Internet applications, the possibilities increase significantly. One good example of how these potentials might play out is AutoWeb, originally conceived as a separate product but now rolled into Aretha. AutoWeb is a tool to build and manage entire Web sites from a hierarchical set of folders and text and graphics files. You need only to look at UserLand’s pages on HotWired to see the intent of AutoWeb. Note the consistency across the pages, the Next, Previous, and Home links, timestamps, and copyright info. AutoWeb also helps with generating anchors and links, plus managing the plethora of text and graphic files that inevitably make any significant Web site look like an escapee from a lost sectors convention. Before you say you’re unimpressed, the point isn’t that the elements on UserLand’s pages are revolutionary, but that they’re automatically managed and hassle-free.
Scripting You — One of the most intriguing – and most controversial – aspects of Aretha’s current integration with Netscape is the ability to embed Frontier scripts within a Web page. This sort of thing has been possible with AppleScript, although not exactly commonplace. However, if you’re running Netscape 1.1N and have Aretha running at the same time, clicking a URL like this embedded in a Web page:
<a href="usrtlk:dialog.alert%20(%22Guess%20who?%22)">click this</a>
tells Aretha to display a dialog saying "Guess who?" on your screen. You’ll notice the "usrtlk:" protocol tag at the beginning of the anchor: this tells Netscape to pass the URL along to the UserTalk language interpreter built into Frontier. (If Frontier isn’t running, the URL generates a standard Netscape error.)
The implications of this idea are promising. The ability to execute script fragments on the client machine via the Web allows considerable custom functionality to be integrated into a Web site, almost regardless of the speed of the connection between the host and the client. It also lends itself to the new "hybrid" online-and-on-disk products that are beginning to appear. Suddenly a Web client can become an interface to a custom application with considerable functionality. With an scriptable application, interactive online tutorials and support via the World-Wide Web are suddenly a very real possibility. And just think what those crazy game developers could do…
Security — Some TidBITS readers will notice parallels between Aretha’s ability to execute scripts on a client’s machine and portions of Java, the language built into Sun Microsystems’ Web browser, HotJava. Sun and Netscape recently announced plans to integrate the Java language into Netscape’s browsers.
One of the issues surrounding the execution of scripts on a client machine via the World-Wide Web is security. In the "usrtlk:" URL given above, it wouldn’t take much more code to delete files or shut down your machine than it does to display that dialog. At the present time, Aretha has no security features built into it: if I created such a URL and you loaded it, you’re at my mercy.
At the present time, the lack of security features is deliberate, although UserLand is very much aware of the issue and plans to roll security into future releases. (It might be noted that there are no security features built into AppleScript for this sort of implementation, either.) The issues surrounding security in script execution are complex and UserLand prefers to wait a bit and do it right, rather than do it wrong and shoot Aretha (and themselves) in the foot.
Support and the Price of Freedom — Make no mistake: Aretha isn’t any more accessible to the average Mac user than Frontier was. However, UserLand has correctly realized that the real audience for a tool like Frontier isn’t necessarily in the general population of Macintosh users, but in the subset that have to manage complex tasks and provide custom solutions across a number of applications. Given the Mac’s popularity both as an Internet client and a server and Aretha’s focus on the world of the Internet and the Web, Frontier may have finally found a niche where it can do more than flourish. By being freely available, Aretha also has a chance to set the standard for scriptability on the Mac and on the Internet.
UserLand has committed to participating and supporting Aretha through the Mac Scripting list at Dartmouth. Check it out for discussion of issues and features of Aretha.