Philosophy question regarding modules file options

[Laird Nelson]

What was the intent behind the -o, -u, -e, -i, -t, etc. modules file
options?  I understand that they are the ancestors of the commit support
files, but some of them run their programs on the server side, some on
the client, and (it seems) all of them run only after the operation has
completed.

I guess what I'm wondering are things like this:

* What was the rationale for saying that the checkout (-o) option causes
the program to run on the server side, while the update option (-u)
causes the program to run on the local/sandbox side?

* What was the anticipated use or intended use for the -o option in
particular?  Did these options also predate the history mechanism or
something like that?

* Can any of these options be used to *prevent* their operations (the
manual sez no)?  The missing piece in terms of access control seems to
be preventing someone from checking out a module; I can't off the top of
my head think of any way to block this.

Thanks,
Laird

--
W: address@hidden / P: address@hidden
http://www.amherst.edu/~ljnelson/
Good, cheap, fast: pick two.