FMServer 5.5 Auto-Update Guide

[dfogle]

Here's a quick "Orientation" for FMP 5.5's Auto-Update feature.

First, open the "AutoUpdateExample.fp5" database that comes with the 5.5 server install.

Examine the fields and scripts in there. The example database is designed to check for and download the Server Administration plugin. You have to duplicate the functionality of all the fields and scripts in this example for any plugin downloading you want to do yourself. When you look at the scripts, it's not always real obvious that one external call - like External("FMA-Version", 0) - needs to replaced with the equivalent call for the plugin you want to work with. In the case of the Troi Dialog plugin, you would need to replace the FMA-Version call (which gets the version of the Server Administration plugi) with TrDl-Version (which gets the version of the Troi Dialog Plugin).

In essence, the plugin updating isn't "automatic". You have to write the scripts that check for and download plugins. One set of scripts per plugin looks like the best way to handle it. It would be better if they had called it the "Scriptable Plugin Download" feature. Downloading plugins isn't really that different from scripting the opening of other FMP files from the server, but you have to use external FMSAUC calls to accomplish the task.

Next, open and examine the existing ".txt" files in the Update folder on the server. Those files are referred to as "PVF" files - "Plugin Version Format" files. The only thing they should have in them is the string that a 'version' call to your plugin returns.

You can duplicate the scripts for creating PVF and MacBinary files for each plugin you want to deal with. You don't need to put those scripts in each database you need the plugin for, just once in a 'development' database is fine. Remember to replace external calls to the Server Administration plugin with equivalent calls to your own plugin. The best thing to do is to create a folder on your own computer that holds all the files for each plugin. You generally will need 3 'sets' of plugin and .txt PVF files: one each for MacOS9, MacOSX, and Windows. So in the Server Admin example, there are a total of 6 files there: 3 different .txt files to handle each platform's plugin, and each plugin itself for each platform. then copy each of those files into the AutoUpdate folder on the server. But don't put the files in any sub-folders in that AutoUpdate folder, or they won't work.

Make sure that you solutions open so that the plugin checker/downloader runs pretty much first thing all the time.

A downloaded plugin loads dynamically. Once the download scripts have run and the plugin is in the System/Extensions folder, it can be called immediately and it works.

The caveats are:

1) The file with the plugin updating scripts must be opened from the server. A locally opened database fails any of the FMSAUC functions that check for plugins/information on the server.

2) The System folder (Win) and FileMaker Extensions folder (Mac) are the only locations which files on the server will be downloaded to. If you need them moved somewhere else from there (non-plugin files), you will need to come up with another solution.

3) You can't do a 'version' call on a local non-plugin file. You'll have to create some other way to divine the 'version' of the file(s). What I did was just checked for the file to exist, and hardcoded the version number in the script that checked for it. It gets kinda messy, though, if you do release a new version of the file, because unless you can dynamically but permanently store the current version on a new version download, you'll get some redundant downloads.

4) The .txt PVF file is just exactly the name of the file in the AutoUpdate folder, with the .txt on the end of it. The only thing it can contain is the name given to the file, and the version. And by name, it would be best to use the actual filename for non-plugin files, but you can actaully use just about whatever you want as long as it matches between the local machine and the server .txt file

5) You still have to .bin any file for Mac download; for Win, the raw file with the original extension must be there.

Best thing to do is play around with it a bit with the info given here, then get back to me with any specific questions.

[ September 05, 2001: Message edited by: Derrick Fogle ]