HCMC Blogs

Meeting with GN, JN, EG-W, and EF re the handover of the labs to USYS. Issues discussed included the fate of equipment currently used in the labs, but belonging to HCMC (projectors, teacher stations, Squash server etc.), notification processes for clients who may be confused by the change (ensuring that Sanako users don't end up in the big lab, where there's no Sanako system), liaison with Continuing Studies, and booking procedures.

Made the following changes, in anticipation of the publication of a paper referencing the site:

1. The main site (http://citystats.uvic.ca/) has now been replaced by the release candidate, so it now includes the wizard.
2. The release candidate has been removed.
3. The beta_site location is still in place, and this also includes the data for Philadelphia. This is basically a copy of the main site, but using a different copy of the database, with the Philadelphia data included.

The beta_site copy can be the basis for any ongoing development, leaving the main site intact. Admin pages for the query storage table are also available on both versions of the site, but password-protected.

Updated lab request/change

Composed temporary in-house schedule.

HC pointed out that sorting by Vol/Issue (by clicking on the TOC table column headers) ignored the editorial sequence of items within issues. That's now fixed. Whenever the TOC is accessed "unsorted", or sorted ascending or descending by Vol/Issue, the individual items are sorted by editorial sequence within the issue.

Added the key update code to TFormStateSaver, and got to the point of compiling it, but haven't yet been able to test it. I'll begin testing in the Markin program at home, then bring any fixes back in. The logic is slightly complicated, but I think it's all functional.

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.

The sort order in the contents page was a bit of a hack, based on an ad-hoc @n attribute in the root element; it worked fine for a single issue, but multiple issues require more sophisticated sorting, so I've replaced that attribute with a more formal designation of each document's position within its issue:

<publicationStmt>
...
<idno type="itemNo" n="03"></idno>
...
</publicationStmt> 

The leading zero makes for easier sorting in cases where perhaps the XPath or XSLT engine doesn't handle strict typing well. The <idno> element is mapped to the <elocation-id> element in the NLM output, giving us better NLM metadata.

The default sort sequence is now more sophisticated: it sorts by volume and issue descending (40, then 39, etc.), then by item number ascending (01, 02, 03...), so that the most recent issues sort to the top, but content within each issue sorts in sequence.

The documents for 40.1 have now been promoted to the published collection, and the editors will announce the publication after they've done a final check.

Following the recent loss of Joe Sheehan and Jim Pusack, the editors sent an in memoriam piece to be included in volume 40.1. This is now marked up, and necessitated also the addition of a new contribution type, which is tagged as "obituary".

Greg had to leave early, so I did late duty again; also pinned in the office by endless Adobe updates on one of the Windows boxes. Can't leave until they're done and I can shut down the machine.

A guy turned up from the chair-fixing folks to fix Stew's chair, and then came back later with new arms, which he affixed.