Version Migration, Installer, Launcher, Distribute Files

[Josh Davenport]

I've been migrating a version 3 multiuser database to 5.5 enterprise.  
The system is poorly architected, and correcting that architecture  
within version 3 is not viable. Here is the basic structure I've had  
to deal with, and my strategy for solving the problem, which is thus  
far working.

We have a file server, with a database directory. In the directory we  
have about 10 multiuser files and about 45 single user files.  
Virtually all of the files have dependencies, and usually open the  
dependencies in their .Initialize procedure.

Users negotiate the directory directly and double click to launch.  
Many of the files could be consolidated with a sudo relational  
rewrite (some have repeating patterns 500 fields wide. Yes, really,  
and again, this was not my design.) A couple of other files are very  
complex, with massive amounts of redundant data that need to be  
filled down to related records when modified. I attempted to rewrite  
this stuff before, but a combination of my faults and Pan3s  
limitations prevented it from being successful.

So the goal has become to move to 5.5 enterprise with as little  
modification as possible. At that point, I will rewrite the single  
user files, with nicely abstracted calls, looking up into the old  
multiuser files. Then I will write a nice replacement for the  
multiuser files, but that replacement will also store data into the  
old multiuser files for lookup purposes. Then finally, I will  
complete the single user file rewrite so that it grabs data from the  
new multiuser files. The old system can then be discarded. I got that  
idea, btw, from how Apple migrated from classic to carbon.

In the old system, shared files resided on the file server, but in  
enterprise, they need to be distributed to the local drives. Because  
changes will be rapid as I move forward, I need a way to efficiently  
get updated files to users. Additionally, I needed a way so that  
files could still open each other, even though they weren't in the  
expected location. So here's what I did, which is thus far  
successful. It is optimized for in-house style development.

1) Built a new directory on the file server.

AEL_LIMS_Folder
-AEL_LIMS_File_Server_Files_ Folder
--singleUserA_File
--singleUserB_File
-AEL_LIMS_Install_Package_Folder
--AEL_Launcher_File                                ;this is the  
installer
--AEL_LIMS_Fonts_Folder
--AEL_LIMS_Local_Files_Folder
---sharedA_File
---sharedB_File
---Reports_Folder
----reportA_File
----reportB_File
--AEL_LIMS_Panorama_Extensions
---Panorama_Folder
----Extensions_Folder
-----Libraries_Folder
------AEL_Library_File

Descriptions:
AEL_LIMS_File_Server_Files_ Folder: this is for single user files  
that only one user can use at a time

AEL_LIMS_Local_Files_Folder: this is for files that are STORED  
locally - on the local drive. They can be shared or single user  
files. I'm putting the single user files into a sub directory

Reports_Folder: this is for single user files that more than one user  
can use at a time - such as a report generator, or wizard, which are  
stored locally.

AEL_Launcher: This file is the linchpin.

2) Built an installer, AEL_Launcher. Here is how it works.

A) AEL_Launcher sits on the file server, inside the  
AEL_LIMS_Install_Package folder. When Launcher is opened, it checks  
to see if it's in this folder. If it is, the first thing it does is  
RECORD ITS OWN FILE PATH into a permanent variable (and updates  
internal file paths, which is explained later) It then copies itself  
to the Wizard directory and writes the preference setting itself as  
the Wizard to open at launch. The copy is done using ExecuteASAP.

B) AEL_Launcher has a configuration form. From the install  
dierectory, I rename and open the database, so the copying doesn't  
run (trapped). On the configuration form is a drop area. I drop a  
folder onto the form.

AEl_Launcher has the following fields:
ObjectType ObjectCreator ObjectName ObjectPath ConfigName

When I drop a folder on the configure form, all the path and name  
info is imported. I then go through the list and check off items that  
I want to be able to open by name. The rest are deleted.

C) the file AEL_Library has custom statements in it. One of the  
statements is aelOpenFileByName. aelOpenFileByName looks up the path  
to a file via the file name (stored in ael_launcher) and opens it.

D) so back to A. The Launcher sits on the file server. I install  
Panorama on a client, and then mount the file server (if only that  
was as fun as it sounds). I then double click Launcher on the file  
server. Launcher opens and sees that its in the Installer Package  
folder. It records its path in the permanent variable and copies  
itself to the Wizard directory and opens itself through ExecuteASAP.

When it opens, it notices that its in the Wizard directory, and  
checks its original location path for files. The first thing it does  
is modifies the path of all RECORDS of files that are in  
AEL_LIMS_Local_Files, so that the recorded paths are now localized.  
It leaves the paths to AEL_LIMS_File_Server_Files alone. It then  
checks the modification date of every file in the  
AEL_LIMS_Local_Files directory, and compares the MODIFICATION date of  
the install package files to the CREATION date of the files inside  
Application Support:AEL_LIMS_Local_Files. If the file server files  
mod date is later than the local copies creation date, it copies the  
file into AEL_LIMS_Local_File in the app support folder. It then  
changes the CREATION date to the MOD date of the file in the install  
package. It does the same thing for the Fonts, and for the  
AEL_Library file.

If the Libray file in updated, it calls to register custom statements.

It then presents an interface form to the user listing all files  
available to open. When a user double clicks on a file,  the file  
opens using the complete path to the file.

As a developer, I set up the system and then start opening files. If  
they crap out, I go to the initialize procedure and replace the  
openfile "whatever" with aelOpenFileByName "whatever". Often times  
you don't need to update every line, because openfile works fine if  
the database is already open.

Advantages:
1) I can copy the entire server directory to a local partition, and  
run Launcher from the install location. It installs itself, and I'm  
now in development mode (though shared files will still try to  
connect. Be careful with them.)

2) When I make a change I want distributed, I just copy the file onto  
the server. The next time the user opens panorama, the files will be  
installed. This could be updated to check every minute or so in the  
future, and or when a file is opened if you are in rapid development  
mode.

3) Users are no longer clicking on files in the Finder to open them,  
so its easy to move the location of files.

4) I can hide support files from the Launcher interface if I don't  
want them opened directly.

5) The entire date check for a pretty good number of files only takes  
a couple seconds.

Hopefully that was clear enough and helpful to someone.

I have to run out to a conference (boring), so I won't be available  
to respond until later. The code in the file needs cleaned up, but I  
think the general method is sound (could be wrong though). Also, I  
suspect a lot of people could use this type of functionality. I can  
make the file available if anyone is interested, and perhaps we can  
weak it until it's a solid Wizard for aiding in house development and  
file distribution.


Josh