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:
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:
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:
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.
When the app is built by the implementors or configured by an adminstrator, it contains the following hard-wird information:
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:
Here's a somewhat-outdated list of points on the order in which files are handed at start-up, the outdatedness being in the mention of the no-longer- existent Config and Init files:
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:
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:
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.