Ideal Application Criteria - Update Features

[BillR]

My only problem with it is remembering to check for updates
periodically.

by Mister Charlie, John Corliss, and Alan brought this question to
mind: What is the best way to update an application.

My ideal application would provide the following:
- Caution during program startup if a) version is older than user
specified age or b) known update exists and provides a direct check.
- Check for update at user specified frequency with optional prior
confirmation.
- Download update with optional prior confirmation with background
(low bandwidth and priority) option.
- Install update with optional prior confirmation.
- Adjust for intermittent connections (e.g., dial-up or broken)
connections. Remember to check for update when a connection is
established. Provide for a delay before checking after a connection.
- Provide for postponing messages as appropriate.
- Provide both a version number and release date for both the
installed and available releases.

I realize that this conflicts with other criteria such as no extra
code, no or minimal registry entries, and optimal processing demands.
For infrequently updated small tools, the caution with a direct check
would suffice. For some tools (e.g., JavaScript in a link), no check
at all is appropriate.

Comments?

BillR

 

[Alan]

The responses to the thread where (e-mail address removed) (BillR)
wrote in message


by Mister Charlie, John Corliss, and Alan brought this question to
mind: What is the best way to update an application.

My ideal application would provide the following:
- Caution during program startup if a) version is older than user
specified age or b) known update exists and provides a direct check.
- Check for update at user specified frequency with optional prior
confirmation.
- Download update with optional prior confirmation with background
(low bandwidth and priority) option.
- Install update with optional prior confirmation.
- Adjust for intermittent connections (e.g., dial-up or broken)
connections. Remember to check for update when a connection is
established. Provide for a delay before checking after a connection.
- Provide for postponing messages as appropriate.
- Provide both a version number and release date for both the
installed and available releases.

I realize that this conflicts with other criteria such as no extra
code, no or minimal registry entries, and optimal processing demands.
For infrequently updated small tools, the caution with a direct check
would suffice. For some tools (e.g., JavaScript in a link), no check
at all is appropriate.

Comments?

All sounds like good, sensible stuff Bill. My usual gripe is programs
that don't provide a lightweight "stub" for the express purpose of a
quick & easy online update. A couple of payware progs I have do this (AV
and ATrojan) but it's more the exception than the rule. Most require you
to fire the main program, which can be a burden on resources when
online. In the case where it's possible to get the update direct from a
site, without opening the program e.g. a virus def file, there's really
no viable reason for the programmer NOT to provide a tiny update
program.

2¢

 

[BillR]

All sounds like good, sensible stuff Bill. My usual gripe is programs
that don't provide a lightweight "stub" for the express purpose of a
quick & easy online update. A couple of payware progs I have do this (AV
and ATrojan) but it's more the exception than the rule. Most require you
to fire the main program, which can be a burden on resources when
online. In the case where it's possible to get the update direct from a
site, without opening the program e.g. a virus def file, there's really
no viable reason for the programmer NOT to provide a tiny update
program.

Yes! A security related update may require some extra processing to
ensure a safe download. I suspect that is why some AVs scan memory
before starting a download.

BillR