One thing lacking from the application is a regular update-prompt system which would help users migrate to new versions (without pushing them too hard). We've been developing a strategy for this as part of the Markin program, and I think a similar system could work for IMT and Transformer. These are the details of the plan worked out so far:

• I. Checking for updates:
  1. App keeps a record of the last time it checked for an update for this user, in the user's Application Data folder.
  2. On startup, it checks that info. If the last check was more than a month ago, it asks the user whether it should check.
  3. If the user says OK, the check is made.
• II. Mechanism for checking.
  1. The update URL is stored in the application itself; it points to a PHP page.
  2. When a check is invoked, the app calls the update URL, appending a GET parameter which includes the current version number:

     [site].../update.php?userVersion=1.8.0.0

     It passes the URL off to the browser, which makes contact with the server.
  3. The update script runs on the server, and creates a customized page which shows the user's current version, the current release version, and a list of all the changes between the two; it also has a link to the recommended download. The page is created by PHP, which simply customizes existing XHTML by including or not including relevant rows in the bug/update table. The page is maintained by me, like HotPot and IMT update pages. When no version parameter is passed to the page, the whole update report table is shown.
  4. The user can choose to download, or, even if they're not an administrator on the machine, they can print the page with all the update info and pass it to the administrator, who can decide if an update should be done.

There's more detail in the Markin development notes. The next decision is how this object should be coded. The options are:

1. A completely distinct object. This would be a bit inefficient, because the object would have to do parsing of version info, and we already have a TAppVersionInfo object to do this.
2. A new feature of TAppVersionInfo. This would require that TAppVersionInfo be able to determine the application data folder, which would make it dependent (currently) on the rather bloated GenFunctions.pas library. Alternatively, the AppDataFolder function content could be abstracted from there and used directly in TAppVersionInfo. On the negative side again, this would require that TAppVersionInfo be able to save and load a file, which is more bloat for an object that's used several times in some of my apps.
3. A new feature of TFormStateSaver. TFormStateSaver is already quite large and complicated; it has its own TAppVersionInfo instance, and is already saving and loading files from the application data folder anyway. All it would need would be a new item to save in the file (the date of the last check), code to read and write it, a field for the URL of the update page, and a function that would construct and call the URL. The GUI aspects could be controlled from the main application, so GUI strings are not required in TFormStateSaver. There would be a function to determine if it's time to check (isTimeToCheckForUpdate), one to get the URL (getUpdateURL), and a property to record that the user was prompted (updatePrompted), which, when set to true, would cause the object to store the current date.

Based on this discussion with myself, I think the last option is the best, and I'll start implementing it. The PHP on the server side is a different problem, but not too complicated either, I don't think.