39

Programming Example

Let's suppose we want a remote Frontier to report to us on the contents and file sizes of everything in its machine's system folder. We will use an approach which allows the scripts that do this to be developed and tested on our own machine.

We begin with a simple adaptation of samples.basicStuff.buildFolderOutline() .

on outlineFolder(path)

    new (outlineType, @scratchpad.otl)

    target.set (@scratchpad.otl)

    op.setLineText (path) « path in main head

    on traverse (path)

        local (f)

        fileloop (f in path)

            op.insert (file.fileFromPath (f) + " " + file.size(f), dir)

            dir = down

            if file.isFolder (f)

                dir = right

                traverse (f) «recurse

                if dir != right «at least one item added from the folder

                    op.go (left, 1)

                dir = down

            rollBeachBall ()

    local (dir = right) «first headline to right of summit

    traverse (path)

    target.clear()

    return true

workspace.outlineFolder() creates at scratchpad.otl an outline of the folder which is its parameter. But initially we don't necessarily know the pathname of the remote system folder, so here's a routine which queries the Finder about that, and hands the result to workspace.outlineFolder().

local (path)

with objectmodel, finder

    path = get (startupdisk.systemfolder, 'TEXT')

workspace.outlineFolder(path)

Once we confirm that these routines work locally, our strategy is to transfer them both to the remote Frontier's database, call the remote workspace.outlineMaster(), retrieve the resulting remote scratchpad.otl, and then delete the remote scratchpad.otl, workspace.outlineMaster, and workspace. outlineFolder. This approach, called "put-run-delete," is very common.

NetFrontier's UserTalk interface provides four actions: remoteGet() , remotePut(), remoteDelete(), and remoteRun(). One should also clean up after a transaction by calling remoteQuit() . The script we shall use illustrates all of these verbs.

with netFrontier

    remotePut(@workspace.outlineFolder)

    remotePut(@workspace.outlineMaster)

    remoteRun("workspace.outlineMaster()")

    remoteGet("scratchpad.otl", @scratchpad.otl)

    remoteDelete("workspace.outlineFolder")

    remoteDelete("workspace.outlineMaster")

    remoteDelete("scratchpad.otl")

    remoteQuit()

edit(@scratchpad.otl)

Literal addresses may be used in referring to the local database, but it is wise to use strings for addresses in the remote database, so that their validity as addresses will not be checked against the local database (see Chapter 8, Addresses, and compare our similar concerns in Chapter 30, Multiple Databases).

To prepare for execution, it is simplest to use NetFrontier's menu interface. First, choose NetFrontier from the Suites menu to bring up the menu interface. Now choose Edit Nodes from the Nodes submenu of the NetFrontier menu to designate the remote computer as a node.

All of the commands in outlineRemoteSysFolder() can take an optional parameter saying what node is to be communicated with, but if this is omitted, the "current node" is used. So, make sure that the remote computer is the "current node," with Select Current Node from the Nodes submenu. Now it is sufficient to click the Run button in the edit window of outlineRemoteSysFolder(). After a while, the outline of the system folder of the remote machine appears on the local machine.

Behind the Scenes

If the remote computer is linked to the local computer by an AppleTalk network, NetFrontier works by creating and sending custom 'netf' Apple events to the remote Frontier. To see, for example, the heart of remoteGet(), look at netFrontier.ATclient.get() ; it sends a 'netf' /'valu' event, and the remote Frontier handles it with the script at system.verbs.traps.netf.valu.

But if the remote computer is linked to the local computer by a TCP/IP network, such as the Internet, Apple events are not involved. NetFrontier packages the call information and hands it over to tcpCmd (see Chapter 38, TCP/IP ), which in turn drives NetEvents to send the package across the network. At the remote station, another copy of NetEvents is functioning as a listener, and is being polled in a separate thread by a loop set up in netFrontier.TCPserver.listener() ; when the package arrives, the polling process picks it up and NetFrontier responds. It is only in this context that remoteQuit() does anything: it closes the connection between the two copies of NetEvents, returning the listener to listening and the local copy to an idle state; by including the call in Example 39-3, we ensure that the script will work over either AppleTalk or TCP/IP networks.

Further Exploration

NetFrontier is well documented, at netFrontier.docs. The following points are worth noting.

• In the previous example, we used the scripting interface to drive NetFrontier. But it is often more convenient to use the menu interface: see the commands in the Nodes submenu of the NetFrontier menu, which let you transfer database objects to and from the remote machine, run scripts located on the remote machine, write your own QuickScript and run it on the remote machine, and perform a put-run-delete of a script object located on the local machine.
• The remote machine's copy of Frontier must be configured to receive communications. For AppleTalk networking, this means that program linking must be turned on, and the next-to-last item in the NetFrontier menu must say Disable AT Server (meaning that it is now enabled). For TCP/IP networking, it means that the user must be given permissions with Edit Users from the TCP Server submenu of the NetFrontier menu, NetEvents must be started up, and Start Server must be chosen from the TCP Server submenu (to put NetEvents into "listen" mode).