| NEXT: Getting Acquainted |
Before there was the Open Scripting Architecture, before there was AppleScript, before there were Apple events, before there was System 7, way back in 1988, UserLand began development of Frontier. Its earliest incarnation, UserLand IAC Toolkit, appeared in 1989. IAC stands for inter-application communication; the program was dedicated to the proposition that if it was going to be too hard for the ordinary user to write an application, it should still be possible to tie existing applications together, acting in concert and communicating with one another.
After System 7 and Apple events had a created a system-level standard for inter-application communication, Frontier 1.0 appeared, one of the earliest programs to exploit them. With its quietly revolutionary scripting language, milieu for editing and storing information in various formats, and database that tied it all together, it was not only the first system-level scripting environment for the Macintosh, but in its own right a tool of manifold usage and great versatility. Frontier 2.0 appeared in October 1992, and Version 3.0 in November 1993.
By this time, AppleScript had been released. At first, AppleScript wasn't commonly available; it could be obtained cheaply, but few people were aware of this. However, Apple Computer soon bundled it with their system software. UserLand responded by doing something revolutionary: in 1995, they began giving Frontier away for free (the so-called "Aretha" release).1
Frontier 4.0 shipped in May 1996, 4.1 shipped in October 1996, and 4.2 shipped in January 1997. These versions firmly established Frontier in the realms of Web site management and CGI scripting. It is a remarkable testament to Frontier's power and flexibility that it had all along been applicable to these areas; the main obstacle was that someone had to realize this.2
With Frontier 5.0, UserLand will embark upon a mission to bring Frontier's scripting power to the Windows platform. At first, this will consist of a subset of Mac OS capabilities, but growth and expansion in new directions are to be expected in the future.
To obtain Frontier, see http://www.scripting.com/frontier/. Here you will learn how to join the Frontier mailing lists, how to access the huge library of downloadable third-party Frontier tools, and what the latest developments are in the ongoing evolution of Frontier.
Frontier is big; even people extremely familiar with it comment routinely on the power and surprises tucked away in the crevices of its database. The new surge of interest in Frontier generated by the Aretha release brought a new problem: Frontier was hard to learn. The printed documentation was outdated and unavailable. Online documentation of new features, though excellent, was sporadic and scattered. The primary paths to learning Frontier were study of the database itself and an oral culture that emerged in the Frontier mailing lists.
It was a frustrating situation. The same questions were being asked repeatedly on the lists as new users came on board, because the answers were documented obscurely or not at all. (To give but one example: the syntax of handler declarations with on, the fundamental linchpin of parameter-passing, was essentially undocumented.) Frontier was getting a reputation as a "geek tool": the only way to learn it was by a sink-or-swim immersion course of intensive study, for which few people had the leisure.
Meanwhile, I had become acquainted with Frontier starting with the free Aretha release, and then, while serving as editor of MacTech Magazine, had developed a Frontier-driven system for automating the transformation of a year's worth of published articles from QuarkXPress to a customized RTF format for republication on the 1996 MacTech CD. The lack of documentation had made the task much harder than it should have been, and soon after, I resolved to systematize my own understanding of Frontier.
Thus, after some weeks of reading all the existing documentation and then studying the entire Frontier database, I developed an outline that brought together, under topic headings for easy reference, the sum total of all that I had been able to discover about Frontier. Armed with this reference, I was quickly able to answer quite a large proportion of the questions that beginners were asking on the mailing lists, even though I was little more than a beginner myself.
At that point, one thing became manifestly obvious to me: Frontier was not difficult. It was not, for example, anywhere near as hard as Ancient Greek, a subject I had for many years prided myself on being able to render crystal clear to anyone possessed of a willing determination to learn it. But learners of Greek did have a resource that learners of Frontier did not: reference books. There were Greek grammars, and Greek lexicons. For Frontier, there was almost nothing. What this program needed was documentation. It needed a teacher. The existence of such resources would prove, I insisted, that the "Frontier learning curve" was largely illusory.
Before I knew what was happening, I had written two online tutorials directed at complete beginners. My original outline was then distributed to users as an online reference; together with the tutorials, it is also the basis of this book.
I have had the joy and privilege of writing the book that I myself wished to read. This is the book I wanted by my side as I was desperately trying to cobble together that automated system for MacTech. This is the book that should have lived beside my computer as a handy reference. This is the book that ought to have been my vade mecum, in cafés, at the beach, in the wee hours. I love reading books like this; I would have loved to read one about Frontier, and now there is one. On the off chance that there exist others who have wanted the same thing, this book is for them, too.
This book is structured in seven parts, as follows:
The book expounds Frontier fully and in logical order, so someone wishing to learn the program completely could read the whole book sequentially, Parts I through VI, consulting Part VII, Reference , as necessary.
But this is not the only way to use this book. Someone wishing to begin immediately with the practical application of Frontier as a Web tool might read Part I and then leap immediately to Part VI, perhaps occasionally turning back to topics in Part IV in order to understand the interface more fully, and only later, when the need and desire arises for more sophisticated customization, advancing to the study of UserTalk through Parts II, III, and V.
Then again, an already experienced Frontier user might see the whole book as a kind of reference, to be consulted piecemeal on individual topics.
Now a word about how UserTalk verbs are explained in the course of the book. Technical details of the sort that would impede the flow of thought and exposition are located in Part VII. In the body of the book, UserTalk verbs are described in connection with what they do : "to achieve this end, use this verb." The parameters are listed, denoted by names that should make their usage easy to divine,3 and there is some supplementary discussion, with advice and examples of usage; but for the details, such as what parameter values will cause a verb to raise an error, see Chapter 46, Verbs , where the verbs appear in alphabetical order. Having discovered in the main part of the book that a particular verb fits your need, you will probably wish to look it up in the Reference section before using it in a script.
A practical and philosophical problem was raised by the fact that during the writing of this book, UserLand was creating version 5.0 of Frontier and releasing public alphas for user comment.
The practical aspect was that since 5.0 promised to represent in many ways a strong break with the past, there was a chance that it would falsify some of the book's information. The situation was made still more complicated by the fact that the 5.0 release was ultimately to include a Windows version.
The philosophical aspect was that I am averse to writing about beta software, let alone alpha: to do so amounts to writing about the future, which is unknown, whereas the fully existing past version can be described with certainty.
The latest fully finished version of Frontier, version 4.2.3, was not outdated or unreliable, and it had the advantage of a stable feature set that could be studied at leisure, whereas 5.0 was a moving target, experimental and constantly being revised. At the same time, it did not seem kind to wait for 5.0 to be completely finished and then write about it; the timetable for 5.0 was unknown, and production of a book after 5.0 was finished would involve still further delay in publication, whereas it seemed to me that users and potential users of Frontier needed a book now.
Accordingly, what this book describes is Frontier 4.2.3 for Mac OS.
The following typographic conventions are used in this book:
We have tested and verified all of the information in this book to the best of our ability, but you may find that features have changed (or even that we have made mistakes!). Please let O'Reilly know about any errors you find by writing:
800-998-9938 (in U.S. or Canada)
707-829-0515 (international/local)
You can also send us messages electronically. To be put on the mailing list or request a catalog, send email to:
To ask technical questions or comment on the book, send email to:
The first acknowledgment must be to Frontier itself. This is a really cool program. The more familiar I have become with it, the more I have been astonished at its cleverness, its power, its elegance, its architectural beauty; every chapter in this book has been an eye-opening experience to write. The makers of the Frontier application, of the UserTalk language, and of the scripts that constitute the database are brilliant, clear-thinking programmers. To study Frontier is to do no less than to look into their minds; and it has been an honor and a privilege to be permitted to do so.
Without Dave Winer and Doug Baron, there wouldn't be anything for this book to be about. Doug could have written this book, and he would have written it much better than I have. Luckily for me, he's too busy to write it. But he has shared his knowledge, with clarity, humor, and rich insight.
The book owes a tremendous debt to the Frontier mailing lists. I have learned from the questions people asked, for these were the yardstick against which the value of the book had always to be measured; I have learned from the answers people gave, for they taught me what I did not know; I have learned from trying to answer questions myself, for in this way I was compelled to codify and clarify my own understanding; I have learned from being mystified by conversations that were utterly over my head, for they reminded me how limited that understanding was.
In particular, I wish to thank the following people. Some of them helped me explicitly. Others probably had no idea that I was looking over their metaphorical shoulders, busily taking notes. They are: Brian Andresen, Henri Asseily, John Baxter, David Bayly, Jay Bourland, Jim Correia, John Delacour, Seth Dillingham, Mason Hale, Preston Holmes, Nobumi Iyanaga, Scott Lawton, Brent Simmons, and Cameron Smith. John Baxter also generously gave of his time to study a final draft of the book and, with his keen eyes and encyclopedic knowledge, saved me from numerous errors.
Sandra Schneible of Bare Bones Software helped at a crucial moment by giving me access to BBEdit 4.5.
Adam Engst and Tonya Engst not only endured my absence from regular editorial contribution to TidBITS without so much as a word of reproof; they actually contributed materially to my stock of tools to get the job done.
At O'Reilly & Associates, special thanks go to Tim O'Reilly, for his insight, kindness, and courage; and to Steve Clark, who tirelessly championed Frontier and this book, and bound up my wounds when, as often happened, I was ready to collapse.
O'Reilly & Associates also lived up to its reputation by bringing to bear the attention and intelligence of its production experts; it has been a pleasure to watch them at work. Mike Sierra converted the book from Microsoft Word to Adobe FrameMaker and provided extensive tools support. Nancy Wolfe Kotary was the production editor and project manager, and did the copyediting. Madeleine Newell was the proofreader. Mary Anne Mayo, Nicole Gipson Arigo, and Sheryl Avruch performed quality checks. Seth Maislin wrote the index.
More than anything else, I was sustained during the writing of this book by people who took the time to write in appreciation of my earlier efforts. I am more grateful than I can possibly express.
Finally, the classic disclaimer: the mistakes are mine. This is not an "insider" book; I have not been privy to special information, but am just an ordinary user, deducing how Frontier works through experience, experiment, discussion, the existing documentation, and study of the database. Sometimes I have been helped, like other users, by the inside experts who haunt the Frontier mailing lists; but sometimes I have had to guess, and it is perfectly possible now and then that I have guessed wrong.
2. This point is eloquently witnessed by Mason Hale, MacTech Magazine 11:12 (December 1995), p. 58: "[I came across] an article Dave [Winer] had written for MacTech Magazine titled 'A Nerdy Guide to Frontier'... I couldn't believe what I was reading; it was like a laundry list of all the features I had been looking for in a CGI environment..." The article that Mason discovered in 1995 had been published in August 1993. On the vision behind Frontier 4.0, see http://www.scripting.com/davenet/96/05/watchthis.html.
| NEXT: Getting Acquainted |