TidBITS: Frontier History

Article 1 of 8 in series

22 Jun 1998 | Print

The Final Free Frontier

The Final Free Frontier -- In brief letters to registered Frontier users last week, UserLand Software announced a charter pricing structure for Frontier 5.1, the soon-to-be-released version of their cross-platform scripting and Web content toolShow full article

Article 2 of 8 in series

02 Feb 1998 | Print

Frontier 5.0 Ships

by Geoff Duncan

Frontier 5.0 Ships -- UserLand Software, Inc., has finalized and released version 5.0 of Frontier, a free scripting environment which includes Web site management, CGI scripting, and network communications capabilities (Frontier's Web site features were reviewed in TidBITS-389)Show full article

Article 3 of 8 in series

21 Jul 1997 | Print

Spinning the Web Part 5: New Frontiers

by Tonya Engst

In recent TidBITS issues, I've been sharing my world view about software that makes Web pages. I started with text editors in TidBITS-384 and continued with visual editors in TidBITS-386Show full article

Hide full article

In recent TidBITS issues, I've been sharing my world view about software that makes Web pages. I started with text editors in TidBITS-384 and continued with visual editors in TidBITS-386. In TidBITS-387, I looked at GoLive's CyberStudio from the page building angle, but CyberStudio also includes site management features, and I promised to cover them soon in tandem with other competitors. First, however, it's time to check out Frontier, which offers a unique environment for Web publishing.

<http://www.scripting.com/frontier/>

Understanding Frontier -- Frontier 4.2.3 is a free, smart database. The software is free because UserLand Software founder Dave Winer decided to release it that way (see TidBITS-279); it's smart because it uses Apple events and a built-in scripting language (UserTalk) to control most anything; and it's a database because it stores information. Frontier is widely used in the Macintosh scripting community, and its users are often passionate about its merits, which include the ability to store components of a Web site and convert them into a complex, automated Web site.

<http://www.scripting.com/frontier/snippets/ features.html>

Exploring Frontier -- You begin exploring Frontier by opening its main table (called the "root"). The root contains entries, each having a kind and a value. For example, one such entry, named "readme," is of the kind "wp text" (word processing text), and if you double-click it, a window opens showing the text and a WP menu appears offering a few word processing commands. Web publishers using Frontier may create and store HTML in wp text entries elsewhere in the database.

Another category in the root, called "user", is of the kind "table" and double-clicking it opens another table filled with user-related items. For instance, one such entry, "organization," took on the value "TidBITS" when I personalized Frontier. Similar entries in other locations let you set how Frontier will publish Web pages. You can navigate Frontier by working through a large hierarchy of tables, or through an outline that reveals and hides different portions of the database.

The Key to the Treasure -- Table entries can also be "verbs," commands that are "called" in Frontier scripts. Using Frontier scripts, a capable scripter can automate most anything on a Macintosh, including other applications. Scripts can be run in different ways: from menus, by opening them in Frontier and clicking the Run button, or by typing their names into Frontier's Quick Script window. Or - to jump ahead of myself slightly - you can call them as you "render" a Web page.

Matt Neuburg, TidBITS Contributing Editor and experienced Frontier user, has commented that "Frontier is the command line to your Macintosh." The following four points are from his comments:

Frontier can drive the System and Finder. It can create, read, copy and delete files, set their types and creators, find out what time it is on your clock, read the clipboard, and more.
Frontier's functionality is available everywhere. It can put menus into other programs, and it can even make double-clickable pseudo-programs.
Frontier talks Apple events much faster than AppleScript does. If an application is scriptable, Frontier can drive it and ask it questions.
Frontier can receive Apple events, which means you can drive Frontier from other applications. Webmasters can use Frontier to process form requests sent in from people browsing Web sites. For instance, one of the top entries in the TidBITS search engine contest (see TidBITS-380) worked this way: Someone searching the TidBITS Web site clicks the search button, WebSTAR (the server software) talks to Frontier, Frontier consults a FileMaker database containing TidBITS issues, and - based what it finds in FileMaker - constructs a new Web page, which it gives to WebSTAR. WebSTAR then sends the page back to the browser.

Frontier's ability to automate most everything, combined with the hierarchical nature of its database, makes it a unique tool for Web publishing. If you use Frontier as a site management tool, you can work from the inside or the outside.

Working from the Outside -- Working from the outside is easier, because you don't have learn to become a competent Frontier user. To work from the outside, you use BBEdit (from Bare Bones Software) to create pages, but you employ the Frontier-created Sites menu in BBEdit to "render" the final site from the raw HTML created in BBEdit.

<http://www.barebones.com/bbedit.html>

It won't take long to learn the basics of rendering. When Frontier renders a raw HTML page (or group of pages) into a site, it employs a complex series of processes and filters that make (optional) changes such as:

Uniform top and bottom matter appears on each page.
Entities replace upper-ASCII characters in the raw HTML (a useful feature especially for people who write in languages like French).
Macros that call Frontier scripts are replaced by their results. (For instance {clock.now()} returns the current date as a result, and there's a script that inserts image tags with automatically generated height and width attributes.)
Email addresses and URLs convert to links.
Quoted text is replaced by an item in a Frontier glossary (yet another Frontier table). For instance, I might want "TidBITS" to be replaced by a link to the TidBITS home page.

If you work in BBEdit, you need not ever explore Frontier, and these features are readily available. If you choose to work inside Frontier, after you get set up, you probably could mostly work from BBEdit as well.

Working from the Inside -- You can use any software you like to create the raw HTML pages stored in Frontier, and then switch to Frontier to take advantage of Frontier's hierarchical approach. Frontier stores each HTML page as a table entry. When you render a site, those entries become separate Web pages, organized in a folder structure that mirrors the structure used in Frontier.

(I've simplified a lot in the paragraph above- rendered pages can be constructed from scripts, or from "outlines." Scripts can assemble pages from most anything you've created or scripted, and outlines have many uses, but I'm not going to delve into them in this article.)

However, using Frontier's hierarchy goes much deeper. For instance, you can have more than one Frontier glossary, and Frontier replaces quoted text based on the glossary located closest to the raw HTML file. (If the glossary isn't in the same table as the raw file, Frontier looks up one level, and keeps looking up one level until it finds a glossary.)

Hierarchies also play a big roll when you use "directives." A directive is a table entry that notes how you want to handle a general aspect of a group of Web pages, such as the background color. A directive can also be placed directly in a raw HTML file. When a raw HTML page renders, directives defined inside it always take precedence. But, if a directive is not defined, the page looks in and up the hierarchy for a definition. Using directives, it's easy to give one branch of a site an orange background and another a green one.

My brain starts to hurt at this point, so rest assured that I've but rippled the surface here. I haven't mentioned templates, the ability to include one file inside another, or the ability to create an HTML-ized site outline. Templates are an especially key feature, and I leave them as an exercise to interested readers.

Rendering -- When a page renders, several filters and processes take place, including running any macros that you've stuck inside it (or its template). This has millions of uses.

As an example, take the new TidBITS home page, which regenerates every hour. Each time the page regenerates, it gets a new, automatically assembled graphic. The new graphic has one of several slogans and a callout to an especially interesting article (or group of articles) that you might want to read. The graphic uses a client-side image map, so new HTML must be created for each new version of the page. Although Geoff Duncan did the work in AppleScript and HyperCard, Frontier could also do the job.

As another example, consider this note from Pam McAllister <pmcallister@pugetsound.org>:

I started using Frontier a few months ago. It took several days to learn the system and import my sites, but now I can handle updates and additions in a fraction of the time it took before. I've added many features, such as indexes of parts of the site, that I would never have time to do manually. I also wrote a Frontier script that puts all the pages into a FileMaker database, which is then searchable on the Web site (using Lasso). Even as a novice scripter, that project took only a few hours. [Check out the SoundWeb site for an example of what Pam has been working on.]

<http://www.pugetsound.org/>
<http://www.blueworld.com/lasso/>

Complexity -- Learning Frontier reminded me of the Far Side cartoon where a student asks to be excused from class, saying that his "brain is full." My ascent up the learning curve was facilitated by an online tutorial created by Matt Neuburg.

<http://www.scripting.com/matt/webtutorial/>

(Matt is currently under contract with O'Reilly Associates to write the first book about Frontier. The book should come out in tandem with the upcoming release of Frontier 5.)

Is It for You? To summarize, Frontier's structure makes it easy to organize HTML pages created in other programs (or in Frontier, though the tools are limited). Once your site lives in Frontier - if you set things up correctly - it's easy to move pages or other resources within the database and to change elements that appear on multiple pages. It's also possible to create Next and Previous links throughout a collection of pages that will be navigated serially. Sites can be rendered to a local folder or via FTP to a remote site. You can render by page, by table, or by what's changed since you last rendered. Frontier is a natural at page rendering that requires automation, especially if multiple applications must work together.

Frontier is pleasant enough to work in, but whether it's worth the time investment to learn depends on the nature of the site. About halfway through my research for this article, I thought Frontier's seemingly boggling array of tables needed an nice user interface badly. A day later, though, it seems accessible and useful. However, if I hadn't already had a good understanding of hierarchies, HTML, macros, and general scripting terms, I would have given up. Further, it's difficult to remember how to use Frontier for running a Web site because the commands aren't obvious on the menus and in the dialog boxes.

You can import a existing site into Frontier, but you must recreate a lot of work by hand to take advantage of Frontier features. Frontier also lacks a few features that you might require. There's no visual view that shows how pages and resources relate to one another, using a spider's web or organizational chart analogy. There's no tracking mechanism for noting which pages are done or who's working on them. Creating unbreakable relative links in Frontier requires working with macros, whereas in other programs, you just drag a picture representing the link destination to the link source. Frontier also lacks a site-wide Find-and-Replace command and spelling checker, as well as a link checker and an HTML checker/validator, though I'm confident that knowledgeable Frontier users can work around those limitations by integrating Frontier with other applications.

Next time, I'll return to the site management features in CyberStudio and also look at other site management software.

Article 4 of 8 in series

29 May 1995 | Print

Frontier Justice

by Geoff Duncan

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 MacShow full article

Hide full article

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:

http://www.hotwired.com/Staff/userland/aretha/

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.

http://www.hotwired.com/Staff/userland/aretha/ autoweb_234.html

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.

http://java.sun.com/

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.

http://mmm.dartmouth.edu/pages/macscripting/ macscripting-home.html

Information from:
Pythaeus
UserLand Software

Article 5 of 8 in series

30 Nov 1992 | Print

Frontier Review

by Adam C. Engst

The main ability that DOS chauvinists have held over Mac users is the ability to create batch files, or as my mother calls them, bat files (for storing in your C:\BELFRY directory)Show full article

Hide full article

The main ability that DOS chauvinists have held over Mac users is the ability to create batch files, or as my mother calls them, bat files (for storing in your C:\BELFRY directory). You use batch files for minor file manipulation and the like, and they're relatively easy to write and use, considering you're dealing with a brain-damaged command line interface. Perhaps the most common batch files that I've seen are those that change directories before running programs, thus ensuring that documents saved from that application end up in a specific place, something which doesn't initially seem applicable to the Mac, but which actually could help neophytes who randomly strew saved files around the hard disk.

Still, many people find batch files useful for automating repetitive tasks, and the Mac has long lacked this ability. Since UserLand Software released Frontier ($190 mail order, $199 direct, $249 list) earlier this year, however, we can all start writing batch files like crazy. After all they're so incredibly useful, right? Maybe, maybe not.

Setting out -- I was pleased as Hawaiian punch when I received Frontier, and I immediately dug into the package to see what I could see. Frontier comes with two manuals - first a Users' Guide that ostensibly explains what Frontier is and why you want to use it. It also explains bits of how to use Frontier, but much more in the "work through this entire book and then you can probably do something useful" mode than the "experiment out of the box" mode that I and many others prefer. The second manual is a reference to all of the statements, verbs in Frontier's lingo, with which you write your scripts. You'll find this manual indispensable, although a pain when you simply want to find a certain verb. Luckily, UserLand provided an Apple event-driven program, DocServer, for referencing this information - that's probably what you'll use much of the time.

I started reading to learn enough for basic experimenting, and the manual immediately provided a few minor examples including a terribly useful script to find all the Microsoft Word documents on your hard disk (Whee! Search and destroy!). Then it branched out to more useful examples such as a script that could backup files modified after a certain date. All this was impressive, certainly, and within the scope of what DOS batch files can do, but frankly, I don't care to find all the documents of a certain sort on my hard disk and when I want to backup modified files I use DiskFit Pro.

I don't mean to slam on Frontier here, but rather to point out that like DOS batch files, Frontier is only as useful as you make it. Frontier will make life easier if you have tasks that you can automate, even if that automation must be of a certain complexity. In fact, the more complex your task the better, since that will make the development time in Frontier more worthwhile.

Here is another example that may improve your quality of computing. You can create what UserLand calls "droplets," or iconified Frontier scripts that can accept drag & drop in the Finder. Someone could create a droplet that takes a floppy and creates an alias of the disk and its contents in a folder on the hard disk, and then ejects the disk. That way you wouldn't have to drag the disk to the trash to eject it (an interface monstrosity of the first degree), and you would have a searchable record of your floppies' contents. That's neat and fairly universally useful.

Travel travails -- So that's perhaps the greatest problem with Frontier - you have to figure out quite clearly what you want to do with it before you start. The average user is unlikely to start playing with it like HyperCard, if only because of HyperCard's graphics and button linking features. In addition, even though HyperTalk bears only a passing resemblance to English, Frontier's UserTalk makes HyperTalk look colloquial. UserTalk is not difficult in comparison to a full programming language (traditional programming languages give me hives) but Frontier uses by no means a trivial dialect. It does a lot, tapping into much of the generalized power behind the Mac's pretty face, and you pay for that power. Although I don't pretend to be a programming aficionado, I gather that UserTalk is a modern language, designed from the ground up without the historical quirks of more traditional languages initially designed on, ahem, older computers and operating systems. Just as the MacOS avoided many of the idiocies inherent in DOS (and as DOS improved on CP/M), so UserTalk improves on other traditional languages.

I recently upgraded my venerable SE/30 to 20 MB of RAM (and I love it) which eliminated another objection to Frontier. I've had to force myself to realize that just because an application supports Apple events does not mean that you can access its power without it running. That makes no sense (that an inactive program could execute instructions), but I believed that for a while for some reason. This is an issue with Frontier because it must be running all or most of the time for you to get much utility from it. Dropping an item on a droplet will launch Frontier if necessary, and if you want Frontier to collaborate with StuffIt, you'd better have enough RAM for both to exist in memory at the same time. Frontier itself prefers 1 MB of RAM, so without at least 8 MB, you're pushing it pretty close. And, as Dave Winer, co-developer of Frontier, points out, desktop publishing and picture editing, especially with Photoshop, are tremendously RAM-hungry so larger RAM sizes are no longer rare. Serious Frontier developers will want plenty of RAM, but those who just want to run scripts written by others should stick with the svelte Frontier Runtime.

I've implied unfairly that you can only use Frontier for writing and executing scripts. In fact, Frontier boasts three other features that add considerably to its overall utility. First, Frontier has what it calls an Object Database, which stores various types of objects such as data, scripts, tables, and so on. Apart from its obvious use as permanent variable storage for script-writing, the Object Database can store pretty much anything you want, so you could use it, for instance to store items in a To Do list, or any other minor databasey thing. You wouldn't want to store huge amounts of data in your Object Database because it holds all of Frontier's data, and is thus quite large and not all that fast. Luckily FileMaker Pro 2.0 works with Frontier, as does a tiny flat-file database from UserLand called uBase. Second, Frontier includes a relatively high-powered outliner, which isn't surprising considering that Dave Winer's most well-known program is the outliner MORE, now marketed by Symantec. Dave's a serious outline fan, and although I see their utility, I have a few personal quibbles with this one, primarily the fact that you can't have an item and then have a paragraph of text under it since Frontier's outliner doesn't word wrap. I'll stick to Inspiration for my literary outlining, but Frontier's outliner is good, and you'll get to know it well since you use it to write your scripts, indenting logical constructions as an actual outline rather than as a readability exercise, another indication of UserTalk's modern design. Third, as I said above, Frontier includes an Apple event-aware application called DocServer, which documents all of Frontier's verbs.

In the real world -- I've lurked in the UserLand forum on CompuServe for some time to sample the flavor of what people do with Frontier, and the main thing I can say is that if you know you need Frontier, then you need it (a nice tight tautology) and if you don't know you need it, you probably won't use it. The corollary to that is that if you need automation beyond QuicKeys, Frontier is your main hope. Tom Petaccia has come up with one of the more intriguing uses for Frontier, using it in conjunction with PageMaker's scripting language to help automate publication layout. Derrick Schneider of BMUG used Tom's glue file (you need one for every Apple event-aware program you want to control with Frontier - UserLand makes them freely available) in conjunction with FileMaker Pro 2.0 and HyperCard to automate the creation of their annual software catalog with Frontier in the middle, linking everything.

How does Frontier compare to AppleScript? I don't know because I've only glimpsed AppleScript. When I asked Dave Winer about it, he didn't appear unduly concerned, which implies to me that AppleScript will fill a different, though partially overlapping, niche. Although AppleScript will let you record scripts, Dave assured me that Frontier will as well when necessary (only StuffIt Deluxe supports this right now). AppleScript looked a little easier, though perhaps less powerful, than Frontier. That does not necessarily imply that it will not have Frontier's depth, but if nothing else, Frontier has had a year head-start on AppleScript and is a mature program. In addition, since Frontier is by definition Apple-event driven; it should coexist happily with AppleScript, each doing what it does best.

However, Frontier is here today, whereas AppleScript lingers in the vaporous shadows. In fact, and I'm surprised I didn't realize this before, Apple is in many ways using a standard IBM technique of pre-announcing a product to kill off the competition. I'm not accusing Apple of trying to knock off UserLand, but in many ways the comparison is apt. It's especially deceptive because much of what Apple does in system software is independent of third parties, but now that Apple charges for System 7.1 and possibly the modules like AppleScript and OCE, the competitive aspect shows more clearly.

UserLand is by no means standing still while waiting for AppleScript. They just released Frontier 2.0, a significant (and free!) upgrade which includes a new method of writing object specifications, the Object Model, which allows people to write scripts to control applications like FileMaker Pro 2.0 and Excel 4.0 that support the Object Model. UserLand included support for HyperCard XCMDs (including many of those that use callbacks to HyperCard 1.x), a proprietary form of external command called a UCMD, and much faster menusharing. Menusharing allows programs to share menus between them, allowing the Finder to have a Scripts menu and StuffIt to have a Frontier menu, for instance. This is way cool, and more programs should support menusharing. All in all, it sounds like a good upgrade, and one definitely worth the 2.0 moniker (numeriker?). Frontier 2.0 has numerous useful enhancements, but since many of them only make sense to users of 1.0 (features like a command-click drop-down menu from each title bar, listing the hierarchy, and multiple selections in the outliner), and since UserLand mailed free 2.0 upgrades to all registered 1.0 users, I'm not going to delve further into the differences.

Keep in mind that Apple events and Frontier can work over a network. I quote from the description of the NightCleanup, a script that ships with Frontier 2.0.

Imagine you're the network manager for a classroom full of Macintoshes. Every day, dozens of students come into the lab to do their assignments and projects. In the course of a day, new files get created, essential files are accidentally deleted. So once a day, you shut the system down and visit all the computers and replace missing files and delete extraneous ones, by manually pointing, clicking and dragging.

NightCleanup - the first UserLand network utility, does this for you automatically and very carefully. It produces a detailed report of all the updating and cleaning up it did. And because NightCleanup is implemented using Frontier scripts, you can customize NightCleanup to exactly suit your needs.

Of course NightCleanup can also serve the needs of network managers in corporations, and even be used to update the files on your hard disk when you return from a road trip with your PowerBook.

Help in the Frontier -- Aside from UserLand's personal help in their CompuServe GO USERLAND forum, there is an Internet LISTSERV discussion list devoted to Frontier, and several file sites that store public scripts. To subscribe to the FRONTIER LISTSERV and receive additional instructions on its use, send email to:

LISTSERV@DARTCMS1.DARTMOUTH.EDU

with this line in the body of the message:

SUBSCRIBE FRONTIER your full name

Since this review is getting longer all the time, I'll wimp out on the details about the file sites and refer you to last week's (TidBITS-153) review of Frontier Runtime, where I gave the pertinent addresses.

End of the road -- I've flip-flopped in this review several times, making points about Frontier's limitations and then in the next electronic breath saying how wonderful it is. I think that reflects my ambivalent feelings about Frontier quite well. On the one hand, I do think it's the neatest thing since HyperCard, and on the other hand, I also think it's a complex wirehead program that will overwhelm many people accustomed to HyperTalk. Even Dave Winer admits that "script writing isn't for the faint of heart," and says that unlike the early HyperCard marketing folks, UserLand doesn't expect everyone to become a script writer. I have written a few scripts and although I eventually get them working, I find it a frustrating process for my little brain (especially considering the paucity of documentation for interaction between programs - take heed developers!). Such is the nature of the beast, and if you are considering writing Frontier scripts, think carefully about what you want first. Then dive in whole hog and enjoy yourself.

UserLand Software Inc.
400 Seaport Court
Redwood City, CA 94063
415/369-6600
415/369-6618 (fax)
76244.120@compuserve.com
USERLAND.CEO@applelink.apple.com

Article 6 of 8 in series

12 Apr 1999 | Print

Frontier Demystified

by Matt Neuburg

Frontier 6.0 has recently been released by UserLand Software, along with a series of press releases consisting of incomprehensible jargon cemented with gobbledygookShow full article

Hide full article

Frontier 6.0 has recently been released by UserLand Software, along with a series of press releases consisting of incomprehensible jargon cemented with gobbledygook. What on earth does it mean that Frontier is a "content management system," or that this upgrade adds "membership, preferences, per-user storage, discussion groups, searching, calendars, news sites, subscriptions and XML-based distributed computing"?

<http://www.userland.com/pressreleases/ Frontier60.html>

Possibly the poor overworked public-relations grunts at UserLand have forgotten what plain language is. Let me try to lend a hand. This isn't a review; it's just an attempt to explain the news. Frontier 6 is here: so what? What is it? To understand, it helps to know where Frontier has been; so let's start with a brief and totally unofficial history. (Big conflict-of-interest disclaimer: I wrote a book about Frontier.)

<http://db.tidbits.com/series/1134>
<http://www.ora.com/catalog/frontier/>

Frontier consists of three elements: a database, a lot of system-level verbs, and a scripting language. The database is a nest of table-like structures where you store and edit information of many different types, such as text, numbers, and even outlines. (If you don't know what an outline is, you haven't been reading TidBITS long enough; the folks who wrote Frontier also wrote MORE.)

<http://db.tidbits.com/article/02542>
<http://db.tidbits.com/article/02381>

The system-level verbs let you do things like create a file, learn the time, and access the clipboard. The scripting language lets you run little programs, called scripts. Scripts live in the database; that's where you create and edit them. Furthermore, scripts can access and control the database. So you should imagine a Frontier script calling other scripts in the database, storing and retrieving information in the database, creating and deleting data structures in the database, fetching and writing information from files on disk, and so forth. For example, Frontier makes it easy to write a script that creates a table in the database listing all the different words in a text document, along with how many times each one occurs.

One major purpose of Frontier, from the start, was to let you send messages to other applications, to tie their functionality together with your scripts. Unfortunately for UserLand, Apple Computer kept upstaging their act. First, Apple came out with System 7 and Apple events, so Frontier supported Apple events as its main way to drive or be driven by other applications. Then, Apple invented the Open Scripting Architecture and its own scripting language AppleScript, so Frontier supported those too. Apple insisted that scriptable applications should support the object model; Frontier implemented this brilliantly.

But even though Frontier, with its incredibly cool and lightning-fast scripting language, plus the database, along with threading, debugging, and many other wonderful features, was arguably a vastly better scripting environment than AppleScript and Apple's clumsy Script Editor, it had a serious drawback: it was expensive, whereas AppleScript was essentially free. So in mid-1995, UserLand did an astonishing thing: they released Frontier for free, too. They also began to re-target Frontier, aiming it at the Web, in three ways:

Automated Web site creation. A lot of what appears in Web pages is boilerplate, such as a set of links that appears at the top of every page; and a lot of it is calculable, such as a Next link that appears on every page, but is different for each page. So, the reasoning goes like this. A Web page is just a file; Frontier can make files. HTML is just text; Frontier's scripting language can assemble text. Frontier has a database to hold the pieces of a Web site; then the scripting language can access those pieces, assemble them, make all the necessary calculations, and spit them out as files. Presto, a Web site of 100 pages is as easy to maintain as a single page.
CGI. A CGI is an application that can accept a message from a Web server, and, in response, can calculate a Web page and hand it back to the Web server. Because Frontier is multi-threaded (and because it can drive other applications with Apple events) it's a perfect CGI application: it can process Web forms, store and retrieve data through scriptable database and spreadsheet programs, drive a scriptable image program to make a GIF chart in real time, format it all into HTML and send it back through the Web server to your browser, with remarkable speed.
TCP/IP communication. Many Internet protocols, like HTTP, are largely text too. So, let's say you've just created a Web page with Frontier, and now you want to upload it to your ISP, where it will be served onto the Web. You could use Frontier to drive a scriptable FTP client to upload the page; but why shouldn't Frontier just "talk" to your ISP's FTP server directly, and upload the page itself? Thanks to a helper program that interfaced with the Internet, Frontier could do just that. It could also talk to a mail server to send or receive email, communicate with a remote copy of Frontier across the Internet, and even act as a simple Web server!

Bear in mind that, to a great extent, the mechanisms performing these feats were just scripts in the database. Thus, Frontier was still the good old database and scripting environment; but the database now included a huge number of scripts aimed at automating Web-oriented tasks. Evolution was then mostly just a process of refining and extending these scripts. This phase culminated in 1997, with Frontier version 4.2.3, the best (I think) of the free versions, and the one my book was about.

The year 1998, with its series of version 5 releases, was directed at making Frontier once again a money-making proposition. This meant that UserLand must resume charging for Frontier, which they now do. To increase its saleability, Frontier was made to run on Windows 95/98 and NT as well as the Mac. And it was raised to first-class TCP/IP citizenship, able to act as client or server with no helper application.

<http://www.userland.com/frontier/pricing.html>

Over the course of the year, there took place a deliberate Grand Unification of the three Web prongs into a single whole, which makes perfect sense if you ask yourself some skeptical questions. Frontier can generate Web pages on demand: so why should it matter whether this demand comes from a user controlling the database by hand, or from a Web server? And why should it matter whether Frontier is sitting behind a Web server as a CGI application, or acting as a server itself? And why should it matter whether material for Web pages enters the database because a user types it in directly, or because Frontier receives it as an email, or as the content of a form submitted from a browser?

It is this Grand Unification which chiefly characterizes Frontier 6. Frontier is now a flexible, programmable milieu for constructing Web-based applications - what the press release calls a "content management system," where "content" means, roughly, "stuff that helps constitute a Web page." Frontier can receive this content in any of a variety of ways, such as email, Web forms, FTP uploads, cut-and-paste, interrogating other applications, and so forth; it can respond by processing this text as desired, perhaps feeding it into a Web form so someone can edit it remotely through a browser; it can ultimately produce, maintain, and even serve the resulting Web pages.

Of course Frontier 6 is still also Frontier 1-through-5, so it includes many years' accumulation of scripts for making Web sites, constructing CGIs, communicating with other applications and across a network, and so forth. Additionally, this new version includes many new scripts implementing various aspects of a Web application; these are examples and starting-points, but they are also ready for use immediately.

For example, you may wish to let various users access different sets of pages and data through passwords and cookies; a system is provided for doing this (referred to as "membership" in the press release). Or, you might want to run a Web-based bulletin board of messages threaded by topic, possibly so people can edit collaboratively (the "discussion groups" feature). Or, you might want your site to be searchable; Frontier 6 includes a customizable search engine ("searching") which indexes Web pages. Or, you might want a daily page of new updates, messages, and links, automatically archived and search-indexed each night (the "news sites" feature). Or, let's say you and I both have copies of part of the database, whose contents must be synchronized; you just choose the Update menu item, and presto, whatever has changed in my copy is downloaded across the network and incorporated into your copy ("subscriptions"). And, intriguingly, the sending of commands and data across the network is done with XML, which is just machine-coded, machine-parsable text; so an application from a completely different conceptual world, such as Perl or Java, could exchange information with Frontier as easily as another copy of Frontier can ("XML-based distributed computing").

So, what exactly does Frontier 6 do? It's easier to say what it is than what it does: it's a completely programmable Internet client/server application that makes Web pages and stores information, along with features for sharing and controlling that information.

As for what it does, properly speaking Frontier does nothing per se. Like any programming language or your computer itself, both do whatever you program them to do. Frontier is open for you to combine and customize and create scripts that give Frontier whatever Web-based application functionality suits your needs. For more information, see UserLand's Web site.

<http://frontier.userland.com/tree$1.2>

Article 7 of 8 in series

06 Dec 1999 | Print

UserLand Releases Frontier 6.1

by Matt Neuburg

UserLand Releases Frontier 6.1 -- UserLand's Web site management and scripting system Frontier 6.0 was described in TidBITS-476; version 6.1 adds many technical improvements, but its most significant innovation is Manila, UserLand's new content management systemShow full article

Article 8 of 8 in series

04 Jun 2001 | Print

UserLand Ships Frontier 7

by Matt Neuburg

UserLand Ships Frontier 7 -- UserLand Software has released version 7 of their flagship program, Frontier. Frontier is a powerful outliner, database, and scripting environment that's frequently used for the creation of Web pages; since it's also an Internet client/server, it is often used as a Web server that creates its Web pages dynamicallyShow full article

TidBITS Watchlist

Expose Shortcut for View All Windows

Recent TidBITS Talk Discussions

Series: Frontier History

The Final Free Frontier

Frontier 5.0 Ships

Spinning the Web Part 5: New Frontiers

Frontier Justice

Frontier Review

Frontier Demystified

UserLand Releases Frontier 6.1

UserLand Ships Frontier 7