Frontier 6.0 ships!
April 02, 1999
Current users can upgrade to 6.0.
Read the Frontier 6.0 change notes.
New server-side features include membership, preferences, per-user storage, discussion groups, improvements to the search engine, calendars, news sites, subscriptions.
In 6.0, Frontier's outliner allows headlines of unlimited length that wrap to the width of the window.
Frontier 6.0 Change Notes
In Frontier 5 we laid strong foundations in HTTP and XML. Frontier became cross-platform, with versions for Windows and Macintosh OS. And for the first time Frontier could manage dynamic sites, where rendering happened as pages are served.
The goal of Frontier 6.0 was to complete the dynamic server, building in common features that benefit all sites, with an eye towards creating dynamic writing environments for people who work collaboratively on the web.
As Frontier 6 progresses, thru 6.0.x and 6.1, the writing environment will build out and the server functionality will be improved.
mainResponder. We wanted a single responder, mainResponder, that did everything, so we could get the details out of the way, details like membership, preferences, storage, discussion groups, virtual domains, subscriptions, a search engine, calendars, cookies, logging, news sites, file uploads. We wanted to be able to edit web pages in a web browser. We wanted an Edit this Page button. And we wanted to get to know the people who use our site. Frontier 6, thru mainResponder, does all this.Now we can be fully creative without having to reinvent the wheel every time we want to put up a new site.
Compatible. While we went for maxium power and performance in Frontier 6, our overriding goal was full backward compatibility with websites built and managed with Frontier 5. Our goal was to leverage all that you learned about website management with Frontier into a new environment, the fully dynamic website.
Dynamic. You may just want to use the dynamic features for testing your websites locally before uploading them to your server to be presented as a static site. Even in this mode, the dynamic features offer a productivity boost for Frontier-based web developers because you get such quick turnaround on your changes. And we are also excited about the idea of web content management applications that run privately on your system. We're already at work on applications of this new idea, as are other Frontier developers.
Control. Another key goal for Frontier 6 was to give the system manager full control over the server. There are security features everywhere conceivable, and a new core table, user.databases, that makes it clear what code is executing and what files can be opened on your server. Logging is implemented at the core of Frontier 6, another key system manager control feature.
A literate outliner. In order to have the foundation for a multi-user writing environment, we needed to improve the core text editor in Frontier, its outliner. The outliner has been improved in a very substantial way, headlines in Frontier 6 have virtually unlimited length, and as a result you can use the outliner to write much more than scripts, templates and specifications. The combination of structure and text editing in one window is uniquely suited to writing for the web, where structured HTML and XML tags can be intermixed with prose. The web is a structured text environment. Frontier 6 is the first software to fully tap this simple idea.
Where we're going.. Having laid a strong foundation in HTTP and XML in earlier versions, and having Frontier running on Windows as well as the Mac, the next thing to do was to create the server environment we wanted to work in. That is Frontier 6. As we go forward, we'll build out the workstation, making it a great writing environment that completely taps the potential of a medium we love and understand, the worldwide web. And of course the writing environment will totally plug into the server environment, thru open standards, of course.
In the following sections we detail the specific changes from Frontier 5.1.6 to Frontier 6. In all cases, more detailed information is available on the Frontier.UserLand.Com website. We're just summarizing the information here so that Frontier 5 users can quickly become familiar with the features in Frontier 6.
Guest databases folder
This new folder holds all the guest databases and supporting files that make up the Frontier 6 environment. It has three sub-folders, www, ops and apps.
www contains files and databases that are accessed thru Frontier's built in web server. By conventionn neither of the other top-level folders are accessible thru the web.
apps contains guest databases that are full applications. They store their configuration data in a new guest database, config.root.
ops contains data files for code that's running in the apps folder. For example, the log files are stored here, as are nightly backups and the guest databases for membership and discussion groups.
A new kind of #attribute controls how objects are served. For example #flrender, a boolean, says whether or not the content should be passed thru Frontier's website framework as it's being served.
Serving from guest databases or the file system
mainResponder views the www folder as a hierarchy. If a URL points to a file, the file is served. If it points into a guest database the content from the database is served. Content in a database can be rendered dynamically, files can only be served statically.
mainResponder creates directory listings -- whether of a table or folder on disk -- automatically, based on preferences.
Membership is handled through cookies. Multiple groups are supported. Membership information is stored in a guest database, members.root, in the ops sub-folder of the Guest Databases folder. Automatic membership registration is handled thru a mail loop, so that a user may register via the web and receive a password in email.
Each user has his own table in the members.root guest database, this is where preference and storage is implemented. The membership cookie is automatically handled by mainResponder, any code can access the member info using the adrmemberinfo element in the paramtable for the request.
Discussion Group: browser-based editing
The discussion group is the back room for a website team: documents can be created and edited in a Discussion Group, commented on by members of the team, and rendered thru one or more live websites once ready for public access.
Discussion group messages can also be indexed by the search engine.
While the discussion group can serve as a public forum, it's also designed to be a groupware writing application.
The discussion group relies on membership: only members can post. Discussion groups may, or may not, be read publicly.
One server can run multiple discussion groups.
Searching is one of the main ways of finding things in a mainResponder-served site.
Indexing is automatic and immediate and can be controlled thru preferences. Web pages that are checked in via WebEdit or created or edited via the Discussion Group are indexed.
Search engine results pages now contain a relevancy ranking percentage, with pages of greatest relevancy at the top.
The search engine keeps track of which pages are most popular for a given search term, so it gets smarter over time, giving greater weight to popular pages.
The search engine server does not have to be on the same machine as the indexed websites: communication is via XML-RPC, which means, for instance, that you can set up a dedicated search engine server and serve websites from one or more other servers.
Time is implemented in mainResponder by providing a standard way of organizing temporal information, and by providing a central routine for navigation thru time.
mainResponder can display browsable calendars for news sites, discussion groups, and other sites that change over time.
mainResponder contains a framework for creating news sites (or weblogs) like Scripting News.
Both the calendar and discussion group play a role in news pages: pages can be browsed via a calendar, and news pages can be edited in a discussion group.
Guest Database subscriptions
You can publish a guest database and allow other people to subscribe to changes made to the guest database. It uses the same mechanism as updates to Frontier.root.
To synch a guest database with the version on the server, the user only has to bring the database to front, and choose the Update command, the first item in the Main menu. You can automate updates via scheduled scripts.
Changes to the guest database are made through WebEdit. Since WebEdit is team software, multiple people may work on the same database.
Rendered page caching
Rendered pages can be cached, so that pages that aren't highly dynamic can be served with greater speed: once rendered they can be cached, and subsequent requests get the page from the cache rather than re-render the page.
Frontier 6 maintains logs for most system functions including mainResponder requests and the search engine and the scheduler. Any of these logs can be browsed thru the web. And log-browsing macros are supplied to make it simple to create custom log browsers.
Multi-part forms and file uploading
Frontier 6 supports multi-part forms, transparently to the application, the parts of the form arrive in the format of a normal POST request.
Config.root, which is created by mainResponder and stored in the apps folder, is the new place for preferences. Frontier applications which are guest databases should store their preferences in config.root rather than the user table in Frontier.root.
A Frontier server can handle multiple virtual domains, simply by setting paths in the domains table in config.root. For example, docserver.userland.com and search.userland.com are served from the same machine, but their sites are completely different.
This ability is not limited to sites with the same name, as in xxx.userland.com -- you could serve www.mysite.com and www.adifferentsite.com from the same machine, and the websites would be different sites. For example, we serve www.mailtothefuture.com from the same machine as discuss.userland.com.
Included with the Frontier 6 distribution is a guest database called htmlInterfaces.root, which contains sample websites that illustrate different mainResponder features and how to use them.
Additional samples are available on the web, including the code for whois.userland.com and http://www.mailtothefuture.com/.
This table in Frontier.root allows you to specify which guest databases should be opened at startup, if their startup script should be run, if they support search engine indexing, and if they can be subscribed to.
A text file at the top level of the Frontier folder can enable or disable some of Frontier's services, over-riding preferences.
It's possible to enable and disable agents, the built-in web server, and opening databases in user.databases.
betty.rpc.client can now, optionally, send XML-RPC messages asynchronously. A new optional parameter, flAsynch, defaults to false: if true then the message is placed in a queue. Other optional parameters, adrCallback and extraInfo, specify the address of a script to call when the message has been sent and extra information available to the callback to help it interpret the response.
It's now possible to not only update Frontier.root but any guest database that supports subscriptions. The Update database menu item at the top of the Main menu changes depending on which database is frontmost, allowing one to update, for instance, DocServer.root and mainResponder.root as well as Frontier.root.
MainResponder supplies the server side of this capability, making it possible for any Frontier software publisher to provide an easy way to get updates to their software.
Two new verbs were created: rootUpdates.update and rootUpdates.threadedUpdate.
Outlines and scripts now wrap to the width of the window. They can contain lines that are greater than Frontier's previous limit of 255 characters.
Frontier's scheduler, builtins.scheduler, now logs optionally to guest databases, which is recommended. The Scheduler menu in the Main menu now allows you to create every minute tasks as well as hourly and overnight tasks.
Frontier's logging code, builtins.log, now logs optionally to a daily log guest database (recommended), outlines, or text files.
New macros and renderers
New macros include two which display Frontier tables in HTML: html.data.standardMacros.nestedTableDisplayer and html.data.standardMacros.hierarchicTableDisplayer.
Two new outline renderers include user.html.renderers.justText, which generates no additional HTML at all, and user.html.renderers.fatHeadlines, which creates bold top-level items and is designed to complement Frontier's new wrapping headlines outliner.
This new verb takes a boolean parameter: true to turn on stats in the About Window, false to turn it off. The stats include the number of scripts running, the id of the current thread, and the available memory, as well as debugging information.
The stats show only when the About Window is expanded.
When stats are on and the About Window is expanded, Frontier may not be as fast: it's a good idea to leave these off or collapse the About Window when you don't need to see the stats.
This new verb creates a new script object in the same way op.newOutlineObject creates a new outline.
A memory leak associated with failed callScript and COM calls was fixed.
Internal Database Error
An internal database error some people were seeing when serving or rendering from guest databases has been fixed.
Two Mac TCP bugs
The first caused tcp.closeStream to crash when the connection was slow or broken. The other caused Frontier to quickly consume all available memory when a PPP connection was broken, leading to an endless succession of Out of Memory alerts.
The number of menu items in the Help menu was shortened, in part to make this menu more useful. It now provides a Search command, and points to the Frontier website, Frontier news page, DocServer, Scripting News, and UserLand Software.