2.14. Multi-User Operating Environment

As discussed in the preceding scenarios, the Calendar Tool Calendar runs most effectively in the context of a multi-user operating environment. While it is possible to use the Calendar Tool as a stand-alone application, the capabilities for meeting scheduling and viewing other users' calendars are key mulit-user features.

There are three separate excutable programs that form the overa Calendar Tool environment:

the Calendar Tool program, for scheduling items, viewing calendars, and performing related functions
the Calendar Tool Administration program, for managing databases and other administrative functions
the Calendar Tool Server program, that handles communcation between the local computers running the Calendar Tool and central host computers that house the databases and shared calendars

Figure 328 is schematic diagram of a typical physical environment for the Calendar Tool system.

Figure 328: .

Here's some fodder nuked from admin that most likely needs to be dealt with here, at leas to some extent:

In order to get all of the meetings from multiple hosts, the user has to connect to them one at a time. By definition, there is no such thing as having the same meeting on two different hosts, since the host field is part of a meeting's unique ID. A scheduler might mess up, however, by scheduling the "logically" same meeting on more than one host, such that a single user hooked up to both hosts will get two copies of the logically same meeting. The multi- user environment section discusses this issue.

The user must be aware of the consequences of changing the designated file for a particular host, as well as designating the same file for two or more hosts. See the details in the multi-user-envir section.

The following paragraph is a slightly extended version of what appears in Section 2.6.6 of admin. It's a decent synopsis that can be reiterated and reworked as necessary to fit in here.

The association of a central host computer with a local calendar file is a fundamental feature of Calendar Tool networking. As explained in the introduction, regular users run the Calendar Tool on local computers, where their calendar files are stored. To support multi-user calendar sharing, there are Calendar Tool central host computers to which users can connect. When a user is connected to a particular host, the associated calendar is the user's "portal" onto that host. When a user connects to the host, a copy of the associated local calendar is sent to the host. While the user is connected, a copy is sent to the host whenever the user saves the local calendar. When another user schedules meetings on the host, the meeting is penciled in on the asociated calendar. Further discussion on these and other aspects of Calendar Tool networking appears in Section 2.14.

Need to include discussion of multi-host-to-calendar associations, since we said in the admin section that we're going to talk about it here.

Also explain that an expected typical mode of operation is for the user to launch the calendar tool with a particular calendar, with that calendar associated with a particular central host, connected to a network with a route that host, and the the default on setting for the option `Auto connect on file open'. This is all quite cool, given that it allows plenty of flexibility, but does the expected-for thing just by launching from a particular calendar file.

Make sure we've adequately defined the terms associated and connected, which we most likely have in admin, but which could probably be reviewed here.

Consider explaining briefly the rationale for putting Connect on the File menu, or perhaps just leave this for the Rationale section.

Old Fodder from admin section:
Describe functions of central host, viz,

facilitates communication among computers of Calendar Tool users
stores calendar information and notifications when necessary (i.e., when user computers are not operating or accessible in the network)
is the computer on which the Calendar Tool database files are located

5aug03 note: Add a couple or more scenarios, along these lines:

User has local cal hooked up to a couple hosts, e.g., dept and campus
Scheduler shouldn't schedule meeting on more than one host
Admin has to take host down for a while, copies files to an alternate host (well, we should probably just leave this one alone; the deal is these days that hosts just don't go down long enough to require an temporary alternate in their place; even if a temp alternate is needed, it should best be transparent to the user, at the higher level of the whole host being (temporarily) replace with a new one. The point is, we don't want to get into the deep do do of general host/server management).

Or possibly these things can just be explained. Here are some notes to his effect.

I believe this still provides reasonable behavior in terms of not having to do a lot of calendar fiddling if you want the same calendar hooked up to more than one host. What it does mean is that in order to get all of the meetings from multiple hosts, the user has to connect to them one at a time. By definition, there is no such thing as having the same meeting on two different hosts, since the host field is part of a meeting's unique ID. What we need to do is have some scenarios of some cases in the Multi-User Environment section, to deal with typical and atypical situations. The conclusion for right here is that it seems to be OK to have two or more hosts associated with the same calendar, but not actively connected to that calendar at the same time. E.g., I can associate my work calendar with the department host and campus host. First I hook it up to the department, and then to the campus. The deal with having conflicts of the "logically same" meeting on both hosts is a scheduler's responsibilitty. It's not much different than getting the same mail message from two different people, and we'll say that it's a human scheduler's responsibility to avoid scheduling the logically same meeting on two different hosts that people might reasonably be expected to hook up to with their (single) calendar. And to finish things off right here, what brought me to this addendum is the realization that having the same cal hooked up to two or more hosts at the same time would create a mosnster fucking mess when in came to the concurrency constraints for meeting scheduling, in that a scheduler could potentially to be put on two or more host queues, which would mean having to change the Concurrent Scheduling section, perhpas substantially, which would be way fucked. (And in keeping with the prime directive of not not doing something just to aviod requirements work, I truly believe that the complexity of queuing up in more than one host queue would be way too motherfucking much.

4aug03 notes on general requirements

General requirements: The system must be implemented and installed in such a way that it can run all the necessary servers on the central host and local user machines. The central host and local client machines can be the same physical machine, e.g., when a number of caltool users are running the multi- user computer that serves as the caltool central host computer.

25jul03 Note about not-yet-accepteds

With the latest setup, there seems to be no problem with determining the visibility of not-yet-accepted items on the central host. Since the user calendar itself has options, the visibility of penciled-in items is as specfied in the option settings in the current copy of the calendar on the host. The security of a pre-notified meeting is that set by the scheduler. Thereafter, i.e., after the user has saved on the host, it's whatever the user sets it to. In general, there's nothing different about viewing user's central host calendar when it comes to not-yet-accepted meetings. Whether or not an attendee is connected, the appears of penciled-ins is based on the current central-host setting of whether penciled-ins are accepted. If accepted on the central host but not yet downloaded to the local machine, their visibility is based on the security setting set by the scheduler. Since there are no options that specifically control whether penciled-ins are visible compared to any other type of item, whenher or not a penciled-in has yet been copied to the local machine has no effect on other-user visibility on the central host. Of course, the user can change the security of meeting once accepted, but then it's just like any other scheduled item in terms of other-user visiblility.

16mar03 Notes
I'm not sure what exactly the current thinking is on the need for the user's local host computer to be known in the user record. What I'm thinking right now is that we can do without it, by using the following model:

A central host only knows about, and therefore only communicates with a user when that user is running the Calendar Tool on some local host computer and has explicitly established a connection with the central host [,NOT: or a daemon on the local host is running on the user's behalf, maintaining a connection with all of the central hosts listed in the user's central host table]. Such explicit connection can happen automatically at start up if the `Auto- connect on file open' option is set to true, but the connection is still in fact explicit.
Given this, the central host can be informed of local computer ID and the user's ID on that computer when the local-to-central host connection is established. This obviates the need for the `Local Host Computers' and `Computer User ID' fields in the user record.
To deal with the case of penciling in when a user is not connected to the central host, all penciled-in meetings will be scheduled on the central host copy of the user's calendar, with no messages or penciled-in meetings being sent to the local host until the connection is again explicitly established from the local host side. This is in fact the idea laid out in Section 2.14.12 below.
In the explanation given in this section of the requirements, we can discuss briefly the analogy of central-host meetings with email messages stored on a remote host. In the case of the Cal Tool, the pending meetings do in fact get left on the remote host, since they're copied to the local calendar, and initially left on the remote host. As soon as the user deals with them locally and saves, they're copied back to the remote host. The fundamental difference between the Cal Tool and an email system, is that a remote email host does not contain a mailbox that other people are intended to see, but rather a spoolig area, where some users may choose to leave messages for some period of time, but such leaving is not for the purposes of having an accurate copy of the local data for the purposes of others looking at it on the remote host. So I think this explains the email analogy as far as it needs to go. To run this shit all the way to conclusion, we need to think through if the idea of having more than one local mailbox be able to download the same message from the remote host. First off, I'm not even sure how valuable a feature this is for email, but assuming it has some value, we should see if it does for calendars. I think the reason it does not is that the correct way to get the same meeting on two or more calendars is not to leave it pending on the central host, but to use a tool like isync that will jointly synchronize two or more calendars, not including the central host. I really do think the best way to regard the central host is as a save-to repository, the also functions as a queue for externally scheduled meetings when we're not connected. The reason we don't want even to sync to the central host calendar, let alone use it as a clearing house, is that we, the local users, don't directly schedule anything on it. I think we're done here with that. The central host is the place that we post our most recent updates for the world to see, and get, as soon as possible, meetings that have been scheduled by others. To get such meetings to other local calendars of our own, e.g., laptop, we copy to or psync to that laptop from the local host where we did the initial connection with the central host. Of course this raises the importance of what is now a future enhancement (i.e., psyncing), but so fucking be it.

Figure 329 shows a typical configuration for a Calendar Tool multi-user operating environment.

Figure 329: Typical Multi-User Environment.

So, if it's still not 100% clear below, here's how things work:

The central host writes to NO local files; rather, it communicates via messaging to the local client, which in turn consults the settings to figure out what files to write to
Accordingly, there need be no, and therefore is no specific named file that is known to the central host as the community calendar.
Rather, there is the following convention, which will be acted upon by the user via (the newly updated) `Central Host ...' dialog: -- OK, go see the latest version of the dialog to see what the convention is.

13aug02 Update: Contrary to the 19jun02 Update just below, I'm feeling much warmer to this section at this point. The deal is that I don't think this stuff is spelled out explicitly and clearly anywhere else. And I don't really think it belongs in the admin section, since not all of the material in this section is directly related to admin commands, one of the most impotant topics being that the host-associated calendar is copied to the central host when it's saved. I suppose we could cover everything in the admin, file, and possibly other sections, however I think it's a good idea to have it all here, in order for all of the multi-user aspects of the system to be laid out clearly.

19jun02 Update: I've always been a tad (to more than a tad) uneasy about the existence of this section. It may be that the new Section on initial system config may be able to cover all of the topics we had in mind for this section. That failing, we may well still want to migrate everything we had in mind for this section into the admin section.

The functional requirements presented in the preceding sections ... . Here's where the art of not over specifying comes in.

NOTE: This paragrpah and the next three discuss two possible ways to deal with not-yet-accepted items. It turns out that the"WAY BITCHEN" conclusion at the end of the next paragraph is bogus, because it says that an important rationale for not doing the local copy of pending meetings is that if the user accepts a meeting off line, then the acceptance won't be immediately recorded on the central host. Well the response to this is, "So what?". There's nothing significatnly more urgent about meeting acceptance than any other change a user might make locally when not connected to a host. Therefore, what all users need to realize is that at any given time, the central host version of a user's calendar is that most recently saved there, which may or may not be the most recent version saved locally. That's just the way things are, and any efforts to try to save things more frequently just isn't worth the hassle. A significantly important reason to copy pending meetings to the local host is so thay don't go away when the connection is shut down. This could be very annoying indeed for users who don't want to remain connected to a host for extended periods of time. E.g., if I'm working at home or on a laptop, my typical mode of operation may well be to treat the central host as a place I visit periodically to get the latest scheduled meetings and upload my latest local changes. In this mode, I'll make a host connection, read through all of the meeting notices as I get them, make the accept/decline/delay decision, save the calendar, then disconect. This kind of sensible and reasonsible behavior avoids the problem of the meeting accept decision being out of date, which is what we thought was so "way bitchen" last March. And to further debunk the "leave pendings on the central host" rationale, it's mentioned below that there's no real physical analog for penciling in in terms of whether it should be local or remote. But, in fact, I think there is an analog, and that is to have penciling in be local. As noted just above, without the local copying, the penciled-in items disappear when the host connection is severed, which strikes me as a pretty inaccurate way to model "penciled in" -- it's the model that the pencil gets erased and rewritten, depending on whether or not there's an active electronic connection to the central host. Recently, I've had in mind that the way a user can avoid seeing penciled-in items on the calendar is just to do the disconnect with the central host. This however strikes me as a lame-ass way to turn a bug (that penciled-in items are transient based on the central host connection) into a feature (that host disconnection is a way to filter out penciled-in items). The addition of the list and filter features for pending items obviates the need to rely on what should be considered a side effect of disconnection from host as the means to filter out pending meetings from calendar and list views. What may be the worst thing about the 16mar03 "way bitchen" conclusion is that it was influenced by the desire not to have to change what at the time was considered to be a completed section on meeting scheduling. As painful as it is, this should NEVER be a rationale for labeling one solution superior to another. If there is an actual deadline, and god knows there do need to be, then the following rationale is fine -- "It has come to our attention that a different solution than is in the current requirements is superior to the current solution, however we don't have time at this point to change the requirements." This assumes that the current solution is not functionally flawed, which I think could be argued for the leave-it-on- the-central-host solution, but is less than optimal compared to another solution that would take too long to put in the requirements. I.e., the bottom line is we can say "we have to live with a less-than-best solution" not that we kid ourselves by calling such a solution the best because we don't have time to fix it.

At present (16mar03), the model presented in the paragraph after next is the one that appears in the nearly-finished meeting scheduling section. This is the model that says not-yet-accepted items are only stored on the central host, and not copied to the local host until accepted. The immediately-following paragraph entertains a different model where not-yet-accepted items are immediately copied to the user's local computer whenever a connection is or has been established. BOTTOM LINE about this: unless I can come up with a very compelling reason to do it the immeidate-local-copy way, we'll stick with the leave-it-on-central-host way. To move things towards conclusion right here and now, I can say that I'm pretty much inclinded to stick with things as is. The rationale goes like this. First, there really isn't a direct physical analog of the central versus local host concepts of an electronic calendar. So, whether "penciled-in" items should be one place or another or both doesn't really have a direct physical analog. So, it's up to us, the specifiers of the electronic calendar, to make some sensible decision about this. The advantage of the copy-it-local model is that it keeps everything on the local calendar, whether accepted or not, so the user can make the local decision whenever she wants. Ah, but this last sentence may well have revealed why the copy-to-local model is NOT in fact the better one. The reason is because when a user accepts a meeting, that acceptance should be recorded on both the local and central hosts. But if the user is not connected to the central host when the acceptance is made, then the local and central copies will be out of psync. Hence, if we leave not-yet-accepteds on the central host, it will ensure (barring the race condition discussed below ) that when the acceptance is made, it's recorded immedidately on both the local and central hosts. WAY BITCHEN -- we've come to the conclusion that we'll leave things as is.

Here's an addendum to the next paragraph (which per the immediately preceding paragraph we're going to nix). We may want to consider a different behavior than having all penciled-in items stay on the central host. For simplicity, we could say that whenever a user hooks up with a central host, all of the penciled-in stuff, and all leader-performed meeting changes/deletions, are fully and immediately copied to the local calendar. If penciled-in stuff has not yet been notified, the notifications appear as well. (Note that this last observation means that I think we need to update the model in include a has-been-notified flag for penciled-in items. After that, the user can do with them as she wants. As long as the user is aware of this behavior, it could be OK. However, since all of the current specs are based on the "leave it on the central host until accepted" model, changing it at this late date may suck. What we really need to do is rationalize which if either model is better, and choose that one. After going aroung in this lilttle addendum circle right now, I thik the argument could go either way. What we could do to make our life really miserable is to make it an option that allows the user to decide whether to leave not-yet-accepted meetings on the central host or to copy them to the local computer.

Draw a nice little picture that shows where the data are actually stored. Viz., in the central repository has a copy of all user calendars, with non- private items and not-yet-accepted (i.e., penciled-in) meetings. Each user has her own copy of the calendar containing all items, including the private ones, but no not-yet-accepted meetings. Hence, when the view commands operate, they are showing information from potentially both the local copy and the central repository. Viz., all local items plus penciled items for each user looking at her own stuff. When viewing another user, everything comes from the central repository. This all means that when the user is disconnected from a central host, penciled-in meetings do not appear. Further, each host has its own, quite possibly different set of not-yet-accepted meetings for a particular user.

Mention the requirement for distributed clock synchronization for comparing the times of scheduler and attendee meeting field changes.

In terms of physical computer configuration, there is no requirement for user's local computers to be physically different machines. In fact, an entire Calendar Tool user community can all be located on the same physical computer, including all users as well as the central host. In such a case, the terms "local" user computer and "remote" central host are conceptual, not physical. The important physcial distinction that always exists is that of user calendars and the central host repository. That is, each user always has a copy of all her or his calendar files in a Calendar Tool directory owned by the user. Also, the Calendar Tool data files are always stored in a directory owned by the Calendar Tool adminstrators. The specific definition of file "owndership" is platform-specific, but abstractly it means the following: the owner(s) of a file (including a directory) have the right to control all access to the file, where access consists of its name, visibility, readibility, writeability, and existance.

2.14.1. The Central Host Server Program

Sketch:

refer to and reiterate as necessary/appropriate Section in admin.html
state that at most one server can be running on any given host
there's no way to start a server remotely from one machine on another machine

2.14.2. The Cycle of Online and Offline Editing

This may be necessary to clarify, via a summary, what goes on editingwise, particularly with meetings. However, if the final version of change/delete and meeting scheduling are enough, then we may not need this section.

2.14.3. Invoking the Calendar Tool from the Operating Environment

There are two separate executable programs named CalendarTool and CalendarToolAdmin. When a user invokes CalendarTool, the system determines if the invoking user is a registered user of the Calendar Tool system. This check is performed by searching for a user record in the Calendar Tool database containing the invoking user's computer ID on the user's host computer. If the system confirms that the user is registed, then the system displays the regular user interface, otherwise it displays the unregistered user interface.

Explain that the system establishes the user's calendar tool ID by matching it against computer user ID. This means, in effect, that in order for a cal tool user to participate in the network functionality of the system, the user must have an account in an operating environment with a user name.

As explained in ..., admin users must login with a password when invoking CalendarToolAdmin.

2.14.4. The Central Calendar Repository

If the item limit value is set such that it is smaller than the current number of items on the user's calendar in the central repository, the system deletes enough items to reach the limit value. Item deletion is performed in the following order, until the limit is reached:

items before today's date are deleted, in order from the earliest to latest scheduled time and date
if further deletion is required, items are deleted in order from that latest scheduled time and

... excised from the admin section: That is, the act itself of invoking Calendar Tool Adminstration defines the invoked-upon computer to be a central host. The adminstrator

Any changes that the adminstrator makes are stored in the Calendar Tool database files for the invoked-upon computer only. There is no means to remotely configure one central host from a different host. If there are to be multiple central hosts in a given operational setting, then each must be configured independently. To avoid highly repetitous data entry tasks, adminstrators may copy Calendar Tool database files from one host to another.

2.14.5. Messaging

Points:

Central system stores all notifications (including host-change messages) until user computers are ready to receive them.
As soon as user machines are ready to receive them, central machine sends them.
Implementors can figure how to do this in any combination of distributed implementations.

2.14.6. Coordination

The central system coordiates the synchronization of meeting schedulers.

OK, we should skip the "hot backup" stuff in the next paragraphs by simply saying that whenever a connected user does file save, the system sends all (formerly public) calendar data to the central host. When this happens, we need to make sure that the not-yet-accepted items on the host are not overwritten. So, we need some kind of rule that says that not-yet-accepted items are separate from the rest of the calendar, at least (and hopefully solely) for the purposes of updating local user changes with the central host. The deal is that whether or not not-yet-accepted meetings are physically separate on the central host, they are conceptually separate in that they stay as is on the central host until they are explicitly accepted or declined by the user. At the risk of over specification (but see the preceding sentences and the last sentence of this paragraph), we should be clear about precisely what portions of a user calendar are kept on the central host. It seems that categories need to be there, given the rules for viewing other users's calendars. Howerver, it seems pretty clear that custom lists, custom filters, and options do not belong on the central host. A detailed walkthrough of all commands is in order to be absolutely sure about this. (Actually, we're not at over-specification risk here, since it is appropriate for data security and privacy reasons for the user to be aware of exactly what data are copied to the central host.)

OK, we need to be very clear about exactly what gets copied and when. Here's some additional information:

On file open or save (including offer-to-save): system attempts connection to host designated for the calendar and if connection is established all (formerly public) information gets copied to designated host (if any), without changing any not-yet-accepted items on the host.
On file close: system disconnects designated host (if any).
On connect: system attempts conection to selected host and if connection is established information gets copied to designated file (must be one), without changing any not-yet-accepted items on the host.
On disconnect: closes designated file.
On receipt of meeting notification from a particular host: system attempts (presumably establishes, unless in rare case host goes immediately down) connection to originating host and if connection is established system does open of designated ncalendar (including, therefore, the copy-to-host specified above for open)

What this means, among probably other things, is that a host cannot be connected without its designated calendar being open. Hope this is cool.

NOT (pre preceding simplification): The central host copy of a user's calendar is kept in a hot backup state whenever the user is connected. This means that effects all confirmed scheduling operations are transmitted immediately to the central host, the only acceptable delay being that of network latency in a particular operating environment.

2.14.7. Implementation Considerations

An important characteristic of the central caltool host is that it is assumed to stay running all of the time, whereas individual users may turn their computers off or disconnect them from the network. If users aren't allowed to do this, then a distributed implementation is allowed. Here's the deal with this -- whenever a caltool user's computer is running and connected to the network, other users can see the latest public items and receive notifications immeidately from that user. Whether they

OK, maybe we do need to be a bit more restrictive in the model than the "weak view" paragraphs below indicate. Try this. From each user's perspecitive, there's her own computer with her own personal stuff and the Caltool host computer, which is the "gateway" to everyone else's stuff. Now, the implementation freedom comes in in how the gateway computer chooses to store stuff. It can either store central copies or ship out distributed copies. If it does the latter, things might get tricky cause it's not allowed to ever let anyone's copy of the "central" database get out of date or inconsistent. As far as the central calendar is concerned, it could in fact be highly distributed. There does need to be a place wher

The following paragraphs discuss a weak view of the implementation:

The idea of the "central" calendar need not be implemented on a single central server, it need only appear that way to users. Viz., from a single user's perspective, the user owns a local file that is her personal calendar. Everyone else's calendar is "out there", accessible when asked for, assuming the computer holding the desired information is running.

The central host computer is where the database information is stored. It may or may not be where a central calendar is stored.

Need to allow the case where central calendar contains references to local calendars, as long as proper semantics are maintained.

2.14.8. Clock Synchronization Issues

These requirements assume that the system clocks for all registered users are synchronized to a common time and date. All implementations of Calendar Tool may consider this assumption to be true.

2.14.9. Files

Next paragraph is WRONG given nixing of ComCal as a distinguished file. User community calendar data are copied in two places -- on the user's local host and the cal tool's central host. The specific local file is that named "CommunityCalendar" in the Calendar Tool directory. Whenever the user saves this file (not for each change), the system sends a copy of the file to the central host to which the user is currently connected, if any.

OLD and WRONG: The central host copy is updated every time the user makes a change, by sending a message to the central host to have the change made.

Admin data are stored in just one place -- the central host, and not copied to users' local hosts. When the user views admin data, she's viewing a the host data directly, cached locally as necessary. However, admin data are never stored in users' local filespace.

2.14.10. Adminstrative Purging of Excess Calendar Data

For large installations and/or for central hosts with limited storage resources, Calendar Tool adiminstrators can purge as much as they want. As a courtesy, they may want to notify users, but they're not required to do so. See the `Admin Purge' command.

2.14.11. Security Considerations

There are no "heroic" ones, such as ones that would try to second guess how a hacker might mess things up by flodding the system with data, or related malicious behavior.

2.14.12. Local/Remote Calendar Synchronization

When a user is disconnected from a central host computer, the local and remote copies of the calendar can get out of sync in two ways -- (1) user adding items locally and (2) meetings being scheduled remotely. To avoid complicated remote/local file comparisons, sychronization is accomplished as follows: whenever a connect is (re)established, the complete contents of the local calendar are copied to the remote host, without changing any of the not-yet- accepted items on the central host. After that, any necessary notifications for new not-yet-accepted meetings (i.e., not-yet-notified meetings) are presented and any leader-changed or leader-deleted meetings are dealt with. (We obviously need to define "dealt with" in the preceding sentence.)

Hmm, there may be a subtle race condition that can occur when a user accepts a meeting and that acceptance is recorded on the user's local calendar, but the connection to the central host goes down before it can be recored as accepted there. We'll need to think through the best way to address this problem. It would appear that it's related to the general idea of failsoft when a computer goes down, i.e., that unsaved calendar changes get checkpointed somehow.

2.14.13. Ramifications of the Accpepting Meeting Notifications Any Time

Being careful not to over specify an implementation, we need to be clear that when the user chooses the `any time' setting for notifications, some form of local Calendar Tool server needs to be active when the Calendar Tool is not running. This server maintains communication with all central hosts listed in the user's current host table, so that any notifications from those hosts can be received and delivered immediately.

Prev: gui-details | Next: installation | Up: functional | Top: index