2.15. Installation and Operating Environment Interface

Cover in as OS-independent way as possible how to install the system, and how it's invoked from the OS. I think the best way to do this is to define what files have to go where, and then say that the installation process can use whateve helpful installation aids may exist, and we assume that the installer has any privileges necessary for installation in system-protected places.

Don't forget to discuss how the server is installed along with the admin program, and that system-level administrator priveleges may be necessary to install such a server. What's described here is the behavior the server must execute -- it's up to the implementors to figure out if such behavior requires system administrator privileges, and if so deal with it accordingly.

2.15.1. Installing the Calendar Tool

Talk (again, as necessary) about the Calendar Tool user directory, the default name and location of which are ".CalendarTool", stored in the user's home directory. Say home how directory is a platform- specific idea, and if there is no such thing on the installed platform, then the user will be asked to specify the name and location of the CalendarTool working directory the very first time the Calendar Tool is invoked.

Bottom line -- when the app is invoked, it must know where to look for the user's CalendarTool directory. Upon initial invocation, if such a directory is not found, it will ask the user to create one. The generic default place for this is ~/.CalendarTool, where "~" designates the platform-dependent "home" directory for the user. This location can be explicitly specified in an adminstirator-created distribution. If at initial invocation the app cannot determine such a location for the invoking user, or if such a location exists but is not read/write accessible to the user, then it prompts the user for the directory path of where to put the CalendarTool directory (with an appropriate msg indicating why it's asking (i.e., cannot figure out where "home" is or the distribution-supplied (or expected) home does not exists or is not read/write accessible)).

Since the user can subsequently change the location of her CalendarTool directory, the app has to be built in such a way to make this possible. The implementors can accomplish in any of the following ways, or some other way of their choosing:

The bottom line is that the way in which the change of CalTool dir is accomplished must remain transparent to all users in that any user can invoke the tool in the normal way (clicking on icon, typing its name) and have the directory location change made by that user be in effect. That is, suppose users A and B are sharing the same copy of the Calendar Tool application. If user A changes the location of her CalendarTool directory to "X" and user B changes the caltool directory location to "Y", the single copy of the shared copy of the CalendarTool will use "X" or "Y" as the location of the CalendarTool directory, when invoked by user "A" or "B", respectively.

Also, given that the `Admin->Distribution' command is gone now, explain how an installer, admin or otherwise, can run the regular cal tool, create calendars and/or a settings files, and include those with an installation. These requirements don't say anything about fancy, easy-to-use install tools, but if they're used, they can do shit like copy installation- provided calendars or Settings files into the user's caltool dir. What we can do in these requirements is explain the manual installation of extra shit, by desribinng the OS-level file commands the the stupid motherfucking user can do to copy the installer-supplied files to his caltool dir.

In conjunction with the precedinig paragraph, we may want to mention that all of the place in the preceding scenarios where it says "by default, there are no ..." is overridden with the installer provides a calenar or Settings file that does define some pre-defined stuff. This is pretty much a duh, but it's probably worth mentioning, just to keep the motherfucking implementors aware and on the hook.

Probably old crap: When installed, the app is additionally configured with the following info:

The application must be compiled for installation following appropriate platform-dependent conventions as necessary.

To create an installable version of the program, these things are needed:

OK, here are the user-level steps to install the cal tool raw, with no administrator-supplied distribution having been provided:

  1. copy the Calendar Tool application program to the desired directory
  2. invoke it
This raw installation assumes that the Calendar Tool user directory, i.e., where Settings, etc go, is

Deal with the conflict resolution issues if one or more of items in a custom distribution conflicting with extant items the user already has defined; I think the best way to deal with that is to give the user an itemized list of precisely what the conflicts are, and let her choose what to do about it.

Want to keep prompts to a minimum. I think these are they, er, this is it:

  1. "Enter the name of the directory where the Calendar Tool will store its standard files. _______________"
Instead of a prompt, conclude the installation with a tip of one of the following forms, as appropriate:

You are a confirmed registered user on the
Calendar Tool central host computer
host name.

You can use the `Admin->Central Host' command
to change your central host or disconnect from the host
to run in stand-alone mode.



-- or --

This installation of the Calendar Tool is configured
to run as a stand-alone program that is not initially
connected to a Calendar Tool central host computer.

If you are a registered user on a Calendar Tool central host,
you can use the `Admin->Central Host' command to connect to the host.

If you are not a registered and want to become one,
please contact your local Calendar Tool administrator.

The first form of tip happens by virtue of a cal tool admin having built a custom config with the default name of a central host set to a host on which the user running the install is registered. The second form happens otherwise.

2.15.1.1. Implementor or Adminstrator Configuration of the Calendar Tool

When the app is built by the implementors or configured by an adminstrator, it contains the following hard-wird information:

2.15.1.2. Platform-Specific File Locations

Talk about conventions that may exist for standard placement of application data files, and how platform-specific installation documentation must be produced for any delivered product. Whatever platform-specific conventions may exist, the following minimum file requirements must be met for all installed platforms: ... (things like the names of files, and the general types of dirs they must go in, e.g. "preferences" dirs).

2.15.2. Invoking the Calendar Tool

Points to include:

2.15.3. Installing the Calendar Tool Administration Program

2.15.4. Invoking the Calendar Tool Administration Program

2.15.5. Location of Calendar Tool Files (Probably Old Crap)

Some directory needs to be designated as a user's caltool directory, and this directory must be that specified in a register's user's central host user database record. The default name for this directory in the standard Calendar Tool distribution is .CalendarTool. System installers and adminstrators must take care that the following conditions do not cause confusion or problems for users:

  1. the installation script, by some funky OS convention, puts the user's cal tool dir is some place like c:336e user's cal tool database record says the user's cal tool dir is someplace else
  2. a user is registered on more than one calendar tool central host, with different cal tool directories, or other different user-record information on thoses hosts
As necessary, expand and elaborate upon these conditions, including explanation of exactly where they're problems or can lead to problems.

2.15.6. Platform Dependencies

OK, I think we probably need to talk about the potentially user-visible platform dependenncies here, not just, or maybe not at all, in the development overview section. See the NOTE at the top of that section.

Among other things, there are the following issues:

  1. command-line args versus clicking on icons
  2. environment vars, particularly ones that define default paths, as in, even more particularly, the path to the start-up Setttings file
  3. the ways files are identified in different environments, including the whole Windoze registry bullshit (if it still exists in XP or whatever the latest POS is)
While details are outdated, here's some fodder on this topic to be groomed/nuked as appropriate:

Note that the value of the local files directory path, user settable via the `File->Local Files' command, is stored in the application program itself, not in a file. There's chicken-and-egg thing going on here [which I'll explain a bit more in due course]. OK, fuck this shit, it's time to explain it now. I think the way it has to work is for at installation time, and never thereafter, the app is configured to look in a specific place for the local-files file, which in turn has enough information to get things boot strapped. It seems most akin to THE ~/.mh_profile, or ~/.emacs, or ~/Library/Preferences/com.apple.mail.plist files. Now in UNIX, we can do things like (1) have a list of places that an app will look, in addition to just the "~" place; (2) use a command-line switch to override the default. I think we should skip the command-line thing, and just say that at installation time, the app is configured with the location of the local-files file, which must stay there forever (for as long as a particular installation is to work), which bootstraps into where the other local files are. Hence, I think the only thing the the installation-time-established "known" file needs to have in it is whatever info is settable by the Local Files command, i.e., either just a directory path or a table that defines one-by-one where each necessary file is; I'm leaning towards the former right about now, not the least reason for such leaning being simplicity and cleanliness.






Prev: multi-user-envir | Next: future-enhancements | Up: functional | Top: index