A different strategy for Windows

The answer will probably surprise some people...

As we currently plan it, Frontier 5.0/Win will not communicate, on its own, with other apps.

Why?

We have a lot to learn about the scripting culture of Windows. We've learned from experience that it can be very hard to take back a poor design decision. It's much better to wait a bit before we move into this area on Windows. People with lots of experience in this area advise us to be cautious. So that's what we're going to do.

Scripted website production

We also prefer this approach from a marketing point of view because it focuses on Frontier's strengths as a web content development platform. We don't need connections to productivity apps or page layout programs to do something unique and valuable.

We only need a simple connection to web browsers to make work flow thru Frontier's website framework (we'll use a DLL for this). The new editorial system software depends on TCP which we are including in 5.0/Windows.

A broader role for Frontier?

Ultimately, how Windows opens to scripting is for Microsoft to decide.

Rather than lead here, as we did in the Mac platform, we're going to acknowledge their leadership on Windows. In the meantime we'll dig into the automated web content market. Plenty of room for us there.

We encourage other developers, including Microsoft, to invest in making Windows a great world for script writers and content developers. We'll follow, when we can; but our philosophy is to stay focused on automated content production.

A staged release

We'll release the software in stages on Windows. It's going to start simple and get more complex gradually.

In the first release Frontier will be able to script the Windows file system and OS, creating new files and directories, moving files around, deleting files; stuff that a batch or shell scripting language would do. You can store scripts in files or in the object database. They can run from the Start menu, which is a poor-man's version of the integration we have with the Mac system Finder. It's a first step.

We've also put an emphasis on getting the outliner debugged and free of display glitches, so you can write scripts that outline a folder, and (for example) create an HTML outline page for a website. This was an essential first step because Frontier's script editor is built on the outliner. Can't have scripting without good outlining.

Brent Simmons, who is based in Seattle, is putting together a collection of sample scripts for the first alpha release of Frontier 5.0 for Windows.

Code extensions for Frontier/Windows

We're going with two approaches for extending Frontier with native code in version 5.0 on Windows.

The first, DLL support, will be in the first alpha release. The functionality is in our development software, and has been reasonably well tested. DLLs, unlike Mac UCMDs, can read and write information in the object database.

The second approach, TCP, is still in development. The interfaces we support will be very similar to the interfaces in the Mac app by Chuck Shotton, NetEvents. We're working with Alan German to be sure the TCPCMD interfaces work in the Windows version of Frontier.

Note: Once all this stuff is working we may change the names of some things to reflect the central nature of TCP scripting in the Frontier environment. The changes we make will be documented, of course.

Pointers

See the Frontier 5 Home page for a list of earlier stories.

On the DocServer website, the file verbs and the outline processing verbs are probably the first ones you'll use.

Calling DLLs from Frontier on Windows. Explains how to write Dynamically Linked Libraries that extend Frontier's verb set.

TCP scripting with Frontier. This site documents the NetEvents stream-oriented interface. A similar interface is being implemented on Windows.

TCPCMD is an interface builds on the stream-oriented interface that allows Frontier scripters to write Internet applications using standard protocols such as HTTP and FTP. Full source is provided.

Frontier adds over 40 commands to the Finder's menu bar. We'd like to get the same thing working on Windows.