by Matt Neuburg <email@example.com>
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"?
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.)
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.)
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.
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.