Application Organization and Updating Mechanism

[Gordon Tillman]

Greetings Folks!

Would you mind taking a look at the following layout for a Form 
Scanning Server application that I'm working on?  This application will 
run on both Mac OS X and Windows platforms and the purpose of it is to 
interface with both Scantron scanners and NCS/Pearson scanners.  It 
will drive the scanners, reading and parsing the scanned form data, and 
transmit the data to a client application which may or may not be 
running on the same computer.

My goal with this layout is to allow this application to update itself 
with updates from a web site that we maintain.  The updates will be 
enhancements or bug fixes.  I want to be able to update all parts of 
the application, as necessary.  It is my understanding that will 
require TWO separate executables because a running application cannot 
replace itself.

So, here is a sample layout on the Mac OSX Side:

Scanning Server.app (this is the application bundle)
   Contents
     MacOS
       Scanning Server (this is the MachO executable.  it
         has a splash screen stack and the runtime)
       Plugins (this is a folder that holds other stacks used
         by the application)
         MainApplication.rev (This is the stack that is
           opened by the splash screen)
         stack1.rev (sample other stack)
         ....
         updater.rev (this stack has the logic for the
           download updates code)
         Updater (this is a MachO executable.  it has a copy
           of the runtime and calls the updater.rev stack
           to do its work)


OK, here is how it works.  The "Scanning Server" mach-o executable that 
contains the splash screen and the RR runtime loads the main 
application stack.

If you want to check for updates to the application, it loads the 
updater.rev stack and does it thing.  If it finds any updated stack 
files, it downloads them (compressed, with the .gz extension, to the 
plugins folder).

If we find an update to the "Scanning Server" mach-o executable, the 
one that contains the splash screen and the RR runtime, then we startup 
the "Updater" executable.  When it starts, it tells the "Scanning 
Server" to quit.  Then it downloads and installs the updated "Scanning 
Server".  When the updated "Scanning Server" has been installed, the 
"Updater" starts it and then quits.


So, under normal circumstances, the "Scanning Server" mach-o executable 
that contains the runtime is the one that loads the other stacks that 
the application needs to function.  One other function of the splash 
screen stack is to replace any old stack files with newly-downloaded 
stack files before invoking the main application.

So the normally-functioning application uses the RR runtime that is 
bundled with the splash screen.  If that splash screen / runtime needs 
to be updated, it uses the second application (the "Updater", also with 
a bundled runtime) to do that job.


Organization on the Windows side is similar:

Installation Folder (holds everything)
   Scanning Server.exe (splash screen and runtime)
   Plugins (folder)
     MainApplication.rev
     stack1.rev (sample other stack)
     ...
     updater.rev
     Updater.exe (the other executable)


So, what do you think?  Does this make sense or am I way off base????

Thanks a bunch!

--gordon