Russell Owen's FileMaker CGI
Version 3.0, 9/1/95
By Russell Owen
Warning: if you are upgrading, please follow the upgrade instructions carefully. Please save your old forms and scripting additions, in case you decide to revert!
- Introduction
- Set Up
- Installation
- Upgrading
- Use
- Serving Your Own Database
- Parameter Fields
- Tips and Known Limitations
- Troubleshooting
- Security
- Support
- Misc
- Source Code
- History
- Disclaimer
- Acknowledgements
- Legal Stuff
ROFM CGI is an application that allows you to serve FileMaker Pro databases to the World Wide Web (WWW). It is easy to set up and use. It runs on Macintosh computers (only), and requires WebSTAR or MacHTTP, Filemaker Pro 2.1v3 and AppleScript 1.1 (which comes with system 7.5). To email notification of new records, you will also need Eudora 1.5 (free) or 2.1 (commercial).
The home site of ROFM CGI is http://rowen.astro.washington.edu/. The full package includes:
- ROFM_Doc.html: this document
- ROFM.acgi: the CGI application. See Source Code for information about reading or modifying it.
- ROFMUtil: a scripting addition containing the code that actually communicates with FileMaker Pro. See Source Code for information about reading it and using it for your own scripts.
- ROFM Databases: a text file listing the databases this CGI is allowed to serve. For more information, see the editing instructions.
- bb.db: a sample database (a simple bulletin board)
- bbAdd.html and bbFindLinks.html: basic forms for adding records and searching the sample database. bbFindLinks.html is liberally commented!
- bbFindTable.html: a fancier form that shows one way to do tables. It, too, is liberally commented.
- SearchInstr.html: instructions for searching FileMaker Pro databases. I suggest you supply a link to this file or one like it from all your FIND and FINDLINKS forms (just as the sample forms do).
- Install the following Scripting Addition files, then reboot:
- ROFMUtil
- Decode URL
- Encode URL
- ACME parse args
- ACME Script Widgets 2.5
To install, drag the specified files (not their folders) into the Scripting Additions folder (in the Extensions folder in your System Folder) and then reboot.
"ACME parse args" and "ACME Script Widgets 2.5" are files in Wayne Walrath's ACME Script Widgets 2.5 package (also available via ftp from gaea). This package is shareware. When you register (with the author, Wayne Walrath, not with me!), please mention that you are using ROFM CGI. I twisted his arm pretty hard to make the parser public (so I could use it in this CGI), and I'd like him to think it was a good decision.
- Put "ROFM Databases" in the Preferences folder (in your System Folder).
- Upgrade your FileMaker Pro to 2.1v3. An updater that works on both 2.0 and 2.1 versions is available from my site. Older versions will probably fail mysteriously.
- Run ROFM.acgi. It should always be running before you try to serve data because it is slow to start up and may miss the first request if it is not already running.
The first time you run the CGI it may ask you to locate "FileMaker Pro 2.1v3" and/or "Eudora". Your applications need not have exactly the same names, and Eudora can be version 1.5.x or version 2.x (regardless of what the CGI actually asks for). If you don't have Eudora and you are sure you do not wish to email newly added records, then you can supply any application instead of Eudora. (If you later change your mind, install a fresh copy of the CGI).
Note that ROFM.acgi tests the scripting extensions (except ROFMUtil) when it starts up, and will report an error if any are broken or corrupted. Fix any problems before you go on!
- If ROFM.acgi asked you where applications are, you should now quit it, so it remembers the information for next time. You will need some patience because it takes about 15 seconds to quit. Then run it again.
- Organize your files. The forms and CGI should stay together in the same folder -- one that WebSTAR can access. The database "bb.db" can go anywhere. (If you want more flexibility in placing the CGI, you may include directory information in the form when you specify "ROFM.acgi", or use an alias to the CGI.)
- Open the sample database "bb.db" by double-clicking it. Your database(s) must always be open before you can serve them.
- Try it out! Run a WWW browser and open one of the supplied forms, such as "bbFindLinks.html", using an http:// style URL (so that WebSTAR serves them). Don't open forms as text files in your browser! WebSTAR must serve forms for them to do anything useful.
If you are upgrading from any pre-release version of ROFM CGI, you may need to make the following changes:
- Change "ROFM.cgi" to "ROFM.acgi" (i.e. change ".cgi" to ".acgi") in all ofyour forms. If you are formatting URLs in your own databases, be sure to make the change there, as well!
- Change "_recSeparator" to "_recPrefix" in all of your forms in which it is used. You may have to change "_header", as well, since "_recPrefix" is now a prefix instead of a record separator.
If you are upgrading from FileMaker Pro CGI version 2.4.1 or earlier, please follow these instructions carefully. For each form, make the following changes:
- Install the new scripting additions; see Set Up for details.
- Put "ROFM Databases" in the Preferences folder in your System Folder. Edit it to include your own databases, as per these instructions.
- The CGI no longer requires the scripting addition files "Replace" or "Tokenize" (these are now inside ACME Script Widgets 2.5). Dump both. Actually, only Tokenize must be dumped. If you have an older script that uses Replace you can keep that around; it got renamed, so there's no chance of a conflict.
- Change 'ACTION="FileMaker.acgi$..."' to 'ACTION="ROFM.acgi"'. Note that the action (ADD, FIND, etc.) has been deleted; it now belongs in a new field...
- Make a new field whose name is "_action" and whose value is the action the form should perform (ADD, FIND, FINDLINKS or GET). This field should be of type "hidden" unless you are certain you want the user to be able to change it.
- Change the name of the field "_databaseName" to "_database"
- Delete the field "_layoutName", if present; it has been superceded by "_field".
- Add a new field (required) named "_field". Set its value to a database field you wish to return as a result of submitting the form. Typically the database field will be a computation field that pre-formats your output.
- If you have a field named "_linkLayoutName", rename it "_linkField" and change its value from the name of a layout to the name of a field.
- If you have a field "_emailLayoutName", rename it "_emailField" and change its value from the name of a layout to the name of a field.
- Change "_recSeparator" to "_recPrefix" in all of your forms in which it is used. You may also have to change "_header", as well, since it is now a prefix instead of a record separator.
Figure out what you want to do
The CGI supports the following actions:
- ADD adds a record to the database.
- FIND searches the database, returning the found data.
- FINDLINKS searches the database, formatting the returned data as links that retrieve full records.
- GET retrieves a single record. It is used by FINDLINKS, but you may also use it.
For more information about these, read about the parameter _action.
Prepare Your Database
Every field you want to access via the CGI must obey certain rules:
- They cannot be repeating fields. (You can probably set repeating fields, but no promises. You definitely cannot read them.)
- The field name must not include special characters, such as spaces, tabs, "+", "=", ":" or "$".
- The field name must not start with an underscore (_). Such fields are intercepted by the CGI.
Create calculation fields to format the returned data. These can include HTML tags, including pointers to images, pointers to other documents, even URLs that access this (or any other) CGI.
- ADD usually wants a fairly complete copy of a field. If you are emailing newly added records, you should probably also create a field that formats the entire record without HTML tags cluttering it up.
- GET can usually use the same calculation field as ADD.
- FINDLINKS wants a brief summary of the record, something that can fit on one line.
- FIND varies, depending on what you are using it for. If you a faster version of FINDLINKS, then produce a brief summary of the record and include a URL that GETs the record.
You must add the name of your database to the file "ROFM Databases". This is a text file in the Preferences folder in your System Folder. It lists every database that this CGI is allowed to serve, and whether or not the user is allowed to add records. Type the name of your database on a new line, and append "=A" if you wish users to be able to add records (instead of just retrieve data). For example:
bb.db=A
aReadOnlyDatabase.fm
aWritableDatabase.fm=A
Note that "ROFM Databases" is only read when the CGI starts up. If you edit the file you must restart ROFM CGI to load the changes.
Create The Forms
Set up at least one form per action, using the samples as templates. The form is a standard HTML document that also contains various fields, including:
- a Submit button, which must be named "Submit"
- a Reset button
- various parameter fields to control the behavior of the CGI. Any field whose name begins with an underscore (_) is a parameter field.
- database fields: fields on the form corresponding to fields in the database. Every database field in the form must have exactly the same name as a field in the database (ignoring case).
If you mis-spell the name of a database field, or include one that does not exist in the database, you will get erratic behavior. Blank fields are ignored by the CGI, so you will only trigger the problem when the mis-named field is actually filled in. And although ADD detects and reports such errors, FIND and FINDLINKS just find zero records, with no explanation (due to poor error handling in FileMaker Pro).
Such problems can be very frustrating and hard to detect. So please always test your forms carefully, filling in every single field. If you can ADD without error or FIND at least one record, with all fields filled in, only then can you be sure that the database field names on the form are spelled correctly.
If you wish to use URLs instead of forms to implement actions, you can easily do this. Format the URL as follows:
<a href= "/ROFM.acgi?fieldName1=data1&fieldName2=data2...">text of link here</a>
Use this format to supply data for every field (except "Submit" and "Reset") that would be on the corresponding form, including both database and parameter fields. For an example, examine the links returned by FINDLINKS.
Parameter fields are special fields in a form used to pass data to the CGI, rather than to the database. Every parameter field's name starts with underscore (_), and in fact any field whose name starts with underscore is assumed to be a parameter field. Many of these fields are optional, and some are relevant only for certain kinds of forms (and are ignored if present on other forms). The parameter fields are as follows:
- _action (required) the action you wish to perform: ADD, FIND, FINDLINKS or GET.
- ADD adds a record to the database. Only fields for which you specify data are set by the CGI; FileMaker itself sets the remaining field to empty, or to a default value if you've specified one in the database. The parameter _field specifies a database field that is read after the record is added. Typically this is a calculation field that formats the acknowledgement in the desired fashion. You may also email data from the new record to one or more users via the parameters _emailTo and _emailField.
- FIND searches the database, returning the found data. Only fields you specify data for are searched; all others are ignored. You may limit the number of records returned using the parameter _maxRecords, and sort the (truncated) found set using _sortField.
- FINDLINKS searches the database, formatting the returned data as links to the records. Typically _field will point to a calculation field that is a summary of information about the record; it should not contain a link to the record, as the CGI supplies that itself. If you are willing to preformat the link, along with the rest of the data, formatting will go significantly faster; but call FIND instead of FINDLINKS.
- GET retrieves a single record. Typically the field to retrieve is specified by record ID number, via the parameter _recID. However, this number is only available via apple events, not within FileMaker itself, so you cannot, for instance, use it in calculation fields. To allow calculation fields within FileMaker to make GET URLs, GET also supports a limited form of searching: you may omit _recID and specify exactly one database field with non-empty data; the first record (in creation order) that matches the search criterion is then returned.
- _database (required) the name of the database file (not the full path, just the name of the file).
- _field (required) specifies a field in the database. Only data from this field is returned as a result of submitting the form. Typically the field is a calculation field that pre-formats the output data; it may include HTML tags including pointers to images, other documents, etc. The returned page is formatted as follows: _header + _recHeader + _field[1] + [_recHeader + _field[2] + ...] + footer, where _field[1] means data from the first record to be returned, etc., and the data in [] is only present if more than one field is to be returned.
- _maxRecords (optional) specifies the maximum number of records that will be returned by a FIND. If omitted or left blank then a default built into the CGI is used.
- _sortField (optional, FIND only) specifies the field by which to sort the found data. The data is always sorted in increasing order of the data type of the database field. There are some caveats to keep in mind:
- Sorting only works with FIND, not FINDLINKS.
- Sorting is very slow, typically adding 10 seconds to a FIND on my PowerPC 7100.
- The found set is truncated before sorting, so if you increase _maxRecords and submit the search again, the returned list may include new data interspersed throughout (rather than just more data at the end).
Eventually I hope to remove these limitations, but cannot at this time due to serious limitations in FileMaker.
- _header (optional): header text for the reply. Should start with <HTML><TITLE> and include </TITLE> and <BODY>. Special characters require hex encoding. _header and _footer both accept the following "variable" strings:
- __currDate is replaced with the current date (long format)
- __nFound is replaced with text describing the number of records found, in one of these forms: "1 record found", "2 records found", "20 records found, but only 10 retrieved"
- __timeList is replaced with timing information of the form: "oper1, oper2, ...: time1, time2, ..., where the operations depend on the action (FIND, etc.) and the times are in integer seconds.
The default header varies according to the action, but the defaults for FIND and FINDLIST both include "__nFound".
- _recPrefix (for FIND and FINDLINKS only; optional): text pre-pended to each record. Special characters require hex encoding. The default for FINDLINKS is <LI> (which is hex encoded %26lt;LI%26gt;). The default for FIND is no prefix. In fact _recPrefix is probably best avoided for FIND unless the prefix is form-specific; you might as well include the prefix in the preformatted output (the calculation field pointed to by _field).
- _footer (optional): footer text for the reply. Should end with </BODY></HTML>. Special characters require hex encoding. Accepts the same "variable" strings as _header. The default header varies according to the action, but the defaults for ADD, FIND and FINDLIST all include "__nFound".
- _emailTo (for ADD only; optional): a copy of the new record will be emailed to the email address(es) specified. If not specified, or left blank, no email is sent. Requires that Eudora 1.5 (free) or 2.1 (commercial) be available, and preferably running. Be warned that emailing messages requires about 5 seconds on a PowerPC 7100, despite the fact that the actual sending of the message is done in the background. (See also _emailField).
- _emailField (for ADD only; optional): the layout used for the emailed record. If omitted, _field is used. See _emailTo for more information about emailing records.
- _recID (for GET only; optional, but...): specifies the record ID number of the field to get. If omitted, then exactly one database field name with non-empty data must be supplied.
Data that the user enters into a form is automatically encoded, so you don't need to worry about it. But data that is an intrinsic part of the form (such as the values of hidden fields) and URLs both require hex encoding of special characters. A hex code is a % sign followed by the character's hex value. Common codes include: less-than (<) = %3C, greater-than (>) = %3E, space = %20, return = %OD, double-quote (") = %22. If less-than and greater-than are to be displayed as text (rather than part of an HTML command) then you must encode the leading & in the HTML special symbols for them: < = %26lt; and > = %26gt;
This is mainly an issue for _header, _recPrefix and _footer because other fields are usually set by the user or don't tend to contain special characters.
- This CGI (and FileMaker Pro itself) are somewhat slow. Here are some hints to speed things up a bit:
- Don't sort. Sorting adds 10 seconds to the search on a PowerPC 7100.
- ADD goes much slower as the number of (non-empty) fields increases. You can really speed things up by designing your database and forms to mimize the number of fields that must be set.
- FIND and FINDLINKS may also slow down with more non-empty fields. However, this may only effect very large databases. Please experiment before trying to fix the problem. If it is a problem, reduce the number of search fields or suggest to the user that they fill in the fewest fields necessary.
- FIND formats data faster than FINDLINKS. You can use FIND instead of FINDLINKS by including the URL to the record in the data returned by FIND. The improvement is negligable if the search only returns 10 records, but quite significant for 50 or more records.
- The optimal memory allocation for FileMaker Pro 2.1v3 is 2.6Mb (according to Erik Bickford). Using significantly more than this can apparently slow things down.
- If WebSTAR is timing out waiting for a reply and you can live with the lack of speed, increase WebSTAR's time limit.
- If the CGI itself is timing out, you can increase its time limit. Edit the CGI code (drag-and-drop the CGI on the Script Editor) and add "with timeout of <n> seconds" and "end timeout" statements around the statements that call FileMaker Pro in the section that is timing out.
- Using a faster language for the CGI would help considerably; I probably will not have time, but would be happy to offer advice if somebody is willing to tackle it. Also, AppleScript itself should get faster over time (the current version is not even native).
- If you prefer you may run ROFM asynchronously. MacHTTP users, especially, should give this a try. Simply rename the file "ROFM.acgi" (change .cgi to .acgi) and change your forms accordingly. The two problems this can cause are:
- multiple users are served in the unfortunate order "last come first served", due to AppleScript's pathetic approximation of multi-threading
- if multiple users attempt to access the same database some attempts may be rejected with a message that the database is busy.
- Have patience. Some of the weaknesses (including ADDs slowness and FINDLINK's lack of sorting) are due to inadequacies in FileMaker's Apple Event support; with any luck things will be better in FileMaker 3.0. Also, the next major release of AppleScript will presumably support proper multi-threading.
- Turn off smart quotes in FileMaker Pro (this is one of the preferences), and eliminate any curly quotes and double-quotes that are in the database. WWW browsers usually display such characters very strangely!
- To serve graphic images, you may store the images as GIF or JPEG files, and serve standard HTML links to the files, e.g. <img src="....GIF">.
- If you want updating of records, Eric Bickford's WEB.FM (a commercial product) offers a limited form of this. Note that WEB.FM is very similar to ROFM; it is written in AppleScript (and FaceSpan), and the interface is nearly identical. The main advantages to WEB.FM are limited updating of records, easier installation, slightly better speed, and potentially better support. The main disadvantages are lack of security (at the time of this writing WEB.FM allows reading and adding records to all open databases), the price, and you don't get source code.
If you are getting mysterious failures, please check the following:
- You have AppleScript 1.1. Older versions will not work.
- You have FileMaker Pro 2.1v3. Older versions will either work poorly or not at all.
- ROFM CGI is fully running; it takes 15-30 seconds to start up, and will not be available until it finishes.
- You have installed the scripting additions correctly and rebooted afterwards. If ROFM doesn't complain about this then it is probably fine.
- If you have a PowerMac then you should have virtual memory on (if you are not using RamDoubler). If virtual memory is off you probably have to increase ROFM CGI's memory partition.
- Try downloading a fresh copy of the CGI; some users have gotten corrupted copies (I have no idea how this could happen, but it clearly has).
If FIND or FINDLINKS consistently fail to find any records, odds are you have a field in your form that doesn't exist in your database (FileMaker unfortunately can't distinguish between this and finding zero records). Check your spelling! You can localize the error by filling in different fields until you find the one that fails.
Serving a database puts it at great risk. A user can write and submit their own forms, so they can do anything the CGI physically allows them to do.
ROFM Databases tells the CGI which databases it should allow access to, and whether or not it should allow users to ADD records. Once you allow access, users can read any field in the database. If you also allow add access, any user can add a record to the database.
WebSTAR/MacHTTP allow you to restrict access to the CGI (restricting access to your forms is not good enough; users can generate their own forms.) Read the WebSTAR/MacHTTP documentation or contact StarNine technical support for help with this.
FileMaker Pro allows you to password-protect various elements of a database, including adding records and reading specific fields. But once a database is opened using a secure username and password it becomes vulnerable to access by the CGI, so this mechanism must be used with great care. Also note that a protected database will ask for a username and password when it is first opened; so automatic startup you will probably require a special script to open your databases. For help setting up usernames and passwords, please read the FileMaker Pro documentation or contact Claris technical support.
That's about all I am willing to say about security. It is a complex topic and I am no expert. Think about what you are doing, test your setup. Please inspect the CGI source code before relying on ROFM Databases. If you are in doubt don't serve your database!
If you have questions or comments about this CGI, or wish to be notified of new versions, please subscribe to the fmpro-cgi mailing list. Instructions for subscribing are available from my site. I do not usually have time to respond to personal email about this CGI. Please do not try to contact me by phone regarding this CGI; I have a day job and would like to keep it.
If you improve the script, please let me know, and if possible email me a copy of the improved script. I would be especially interested in hearing of a translation to a faster language.
ROFM.acgi is written in AppleScript and includes commented source code. To view or edit the source code first make sure ROFM.acgi is not running, then drag and drop it onto Script Editor. If this fails, try increasing the memory partition of Script Editor! For your protection, please only edit a copy.
ROFMUtil is also written in AppleScript. It is a "compiled script" that contains the code that communicates with FileMaker Pro. This code may prove useful for other FileMaker scripts, as well. There is, at present, no documentation aside from the comments in the source code. To read the source code, simply double-click the file to open it in Script Editor. For your protection, please only edit a copy.
Please do NOT modify ROFMUtil unless you know what you are doing. FileMaker Pro Apple Event support is incredibly weird and tricky, and Claris' own documentation is dead wrong in a number of places. Don't even think about changing things unless you are willing to do a lot of experimentation or already have a lot of experience. Some warnings for bold coders:
- ROFMUtil will not recompile unless you delete the word "transaction" wherever "end transaction" appears. This is an idiocy in Script Editor, and is commented in the source code.
- ROFM.acgi loads ROFMUtil when ROFM.acgi is compiled. So if you change ROFMUtil you must then recompile ROFM.acgi to use the changes. (ROFMUtil is ignored except when ROFM.acgi is compiled, so asking users to install it in Scripting Additions is more insurance than necessity.)
- 3.0 Added sorting via _sortField (it's slow, and only works with FIND, but it's a start). Add the security file "ROFM Databases" (thanks to Jeff Clough and Don Napoli for getting me to think about a better security system). Modified the syntax for the action GET. Now all actions can be implemented using the POST method (forms) or GET method (encoding the parameters in the URL). (Thanks to Jeff Clough for prompting me to finally do this). Now sends email as well as queuing it. Many speed-ups. Renamed the CGI from FileMaker.acgi to ROFM.acgi. Modified to use ACME Script Widgets 2.5 and ACME parse args. Parameter name parsing is no longer case sensitive. Modified to handle the CERN proxy problem. Almost all of the parameter fields have changed. R.O. 9/1/95
- 2.3.1 fixed a nasty bug (reported by Marco Pagliano) in ADD that could result in writing data to the wrong database, corrupting existing records. R.O. 5/25/95
- 2.3 changed ADD email to send a formatted record rather than a URL, and so added the _emailLayoutName field. Changed ADD to only set fields that aren't left blank. R.O. 5/24/95
- 2.2 ADD forms can email a link to the new record (see field _emailTo). The search instructions are much more comprehensive and are now on a separate page (which you are welcome to use or modify). Some code clean-ups -- getting lists from FMPro is nicer. R.O. 5/22/95
- 2.1.1 Only the documentation changed. The documentation included some bad links and incorrectly listed _linkLayoutName as _ptrLayoutName (thanks to Sam DeVore for pointing this out). R.O. 5/12/95
- 2.1 Removed auto-loading of database files (and hence the need to configure the CGI!). Make sure the databases are open before serving them. Removed excess restrictions on database and layout names added in 2.0. Better documented some genuine restrictions in field names. Major bug fixes to error handling (it was pretty broken), which also simplified the code. Added performance feedback to help you optimize your forms and databases. Removed the use of clientAddress by ADD forms. R.O. 5/11/95
- 2.0 Finally added FINDLINKS and GET support. As a result, the CGI now requires a new scripting addition: Encode URL. Also, the CGI now quits to save changes after being configured (fixing a problem reported by Douglas Wyatt). R.O. 5/8/95
- 1.4 Added special handling of layouts with only one field in them: returns the data "raw", allowing custom formatting (you'll also get higher performance). Smarter handling of searches; if a user only fills one data field on a FIND form the search should go significantly faster (for large databases). Searches with only a few fields filled in may also go more quickly. Also fixed a bug discovered by Gerry Paille that could cause the wrong database to be searched (I still wasn't referencing the database by name while retrieving records during a search). Finally, I had not removed "Show All Records" in 1.3.1, despite claims to the contrary, but have done so now in this version. R.O. 5/95
- 1.3.1 Minor change: removed Show All Records, which one user (whose name I've lost) claims speeds it up a bit on large databases. I've tested this change extensively but still worry I've missed something. If your searches start missing some records, please let me know. R.O. 3/23/95
- 1.3 Fixed a bug discovered by Lee Riggs: if a layout had only one record the returned page was screwed up. Also, the configuration application handles errors better and does most of the configuration work itself; this should make it less confusing to use, though still not wonderful. R.O. 3/11/95
- 1.2.2 Documentation changed to an html file. R.O. 3/3/95
- 1.2.1 Added code to check for the required scripting extensions. R.O. 3/3/95
- 1.2 Added user-settable limit on # of records returned; handles large #s of records much better. Fixed a bug involving multiple databases (I forgot the "of document databaseName" in two places). R.O. 3/2/95
- 1.1 Added named layout support, for limiting which fields are shown in replies. R.O. 3/1/95
- 1.0.4 Made a separate application to configure the CGI, so there is no need to edit the script to configure it. Removed the maintainer's name and email address from the GCI's error feedback page, making the CGI easier to configure. R.O. 3/1/95
- 1.0.3 Removed the auto-quit code; I could not see how to make it reliable. R.O. 3/1/95
- 1.0.2 Moved the documentation into a separate file. Now supports returns in text areas (the problem was display, not data entry). Now ADD reads and returns the record added, giving more info and greater assurance the add worked. Increased the application size to fix an annoyance added in 1.0.1: a complaint when quitting. R.O. 2/28/95
- 1.0.1 Fixed a bug in the sample database (clientAddress was of type Number, preventing searches on it). R.O. 2/27/95
- 1.0 Released. Russell Owen, 2/27/95
Chuck Shotton wrote and David Poteet had modified the original CGI on which I based mine. Eric Bickford supplied a lot of useful information on getting the best out of FileMaker Pro. Some of Jon Pugh's excellent tips (posted to the MacScrpt mailing list) have been incorporated. John Baxter gave me a huge amount of help in an attempted conversion of this script to Frontier (which I may yet finish if Frontier gets faster). Thanks finally to the many users who have suggested improvements, reported bugs, and been generally supportive; you have made working on this CGI very rewarding.
This software is not guranteed in any way. I have attempted to make it robust and useful, but make no promises as to the results. You use this software entirely at your own risk.
Copyright © 1995 by Russell E Owen. All rights reserved, except that you may use ROFM CGI without charge. If you wish to distribute this software, please make arrangements with me; at the minimum I will ask for assurances that you will keep your distribution current and will not charge for distribution.
Russell E. Owen
http://rowen.astro.washington.edu/
owen@astro.washington.edu