InterBase Software Updates System

This document describes an implementation to update InterBase applications over the Internet, enabling notifications to be posted at a central site, and clients to poll for software updates.

Update Mechanism

To find out if newer software is available a client program should request a document from a well-known URL.

The document should then be parsed by the client program, to inform the user about newer releases, notifications, and where to obtain them.

The document has the following format:

document  ::= <header>
              CRLF
              [(<topic>)]

header    ::= major_version "." minor_version
              CRLF
              last_update_date
              CRLF
              topic_count

topic     ::= <topic_header>
              [(<topic_body>)]

topic_header  ::= topic_name
                  CRLF
                  topic_description
                  CRLF
                  last_update_date
                  CRLF
                  body_line_count

topic_body    ::= [(body_line)]

major_version is an integer number. Changes in this number mean that backward compatibility was broken in some way. minor_version is an integer number. Changes to this number mean that there is extended information, but that older clients can still interpret this correctly. last_update_date is the date the document last updated in any way, in yyyy.mm.dd.hh.nn format. topic_count is the number of topics which follow the document header.

topic_name is a short name, which uniquely identifies a notification topic. It is typically a file name. topic_description is a user-friendly description of the notification topic. last_update_date is the date of the last update issues on this topic, in yyyy.mm.dd.hh.nn format. body_line_count is the number of lines the body of the topic has.

The body of the document is a plain-text sequence of lines, which are meant for the user to read. Among the contents of the body, it is expected that the following topics will be addressed:

• Why there is a notification.
• What changes have been made.
• Where can the newer version of the software be obtained.
• Where to ask for further assitance.

User Interface Guidelines

There are two instances in which the software updates system should be run: automatically, on application startup, and on-demand.

The automatic startup should be performed silently. The application should not connect to the Internet if the user isn't already connected. If any errors arise, they should be silently discarded. If updates to the relevant software are found, then the user should be notified in a non-modal window.

The on-demand scenario occurs when the user explicitly requests that updates be checked. Errors should be reported. If updates to any software are found, then the user should be notified in a modal window.