Umbrellas for iStorm

Things break inevitably. The more creative you are, the more often it would break. Not taking risk is the most risky thing to do.

Enough of this non-sense from the spokesman for the programmers. In truth, you will occasionally run into an impasse due to imperfection in iStorm or in your network condition. And this tends to happen only when the collaboration was just getting interesting. Here is what you may try in such emergencies, until we waterproof the future version of iStorm.

Using Panic Items in the Menu
  • It pays to SAVE often. That way, at least someone in the group has the up-to-date copy of the group work, and in the worst case, the whole group can start from there afresh.

    • If not, before folding the table, try one of the items from the sub-menu humorously titled "Advanced" in the "Connections" menu. Please do not try them if not as the last resort. Some of the items are available only for the host. As someone who did extra work to set up a collaboration, we thought he or she deserves some extra control. They will be gray-out for non-hosts.

  • Unlock Keys The most benign problem may arise because some of vital exchange of information got sucked into a network congestion. This could have left the server in an inconsistent state, especially leaving its content in a "locked" state. Any subsequent attempt to change the document may be bluntly ignored even when your button indicates green or blue. Although we do not encounter this in our test anymore with iStorm 1.1 or later, it may still happen. Here is what you do: in the Connection menu, go to the submenu called "Advanced", find the item called "Unlock Keys". It is safer if you do this when everybody has green button.

  • Force Local More serious trouble may have left your connection in such a mess that you really feel like opting out to rescue whatever remains on your machine. Item called "Force Local" will force you dropped from collaboration into the local mode. This is similar to the normal "disconnect" action, but this time you do it without notifying the other members of the group. This may leave other people (if they are still there) in a slightly confused state since they may still have you in their list. But what do they expect? You didn't cause this yourself! As a penalty, you may have trouble joining again later, since the server still carries your (ghost) name with it and may refuse your reentrance in certain situations.
    • Server only
  • Server:Force Yield As the server, you (and only you) have the authority to make anybody in the group yield control of the document. This is for when, for either a psychological or physical reason, one can not let go of the hold on the document. The item called "Server:Force Yield" will cause the document to be freed. (assuming that everybody still listens to and obeys you....) If your collaborator keeps you on hold for unreasonable duration, bribe the leader of your group to exercise this option.

  • Server: Fresh Copy As mentioned earlier, the iStorm 1.1 or later (equipped with what we call transport protocol 2.0) employs an intelligent cashing mechanism for pictures in the document. When network congestion forces an update process terminate prematurely, some members in the group may end up with a corrupted document. A symptom will be that a picture is replaced by the character "~". Red *** S O S *** chat message will be sent everyone to alert. If there is such a complaint, the server should issue the "Server: Fresh Copy" command immediately. It will initiate a process where every member will restore the document to the state when it was updated the last time. (just one cmd-return key ago) It will be rather unfortunate for someone who is in control and is busy editing it, since it will be lost, but it is better to pull everybody up to speed before it gets irrevocably out of control. As you know by now, it is possible for the server to remain serving while not being a client to oneself. That is, one can do all the drudgery not participating in the collaboration by disconnecting from oneself. In that rare situation, one should not exercise this option as it will replace the group work with whatever is locally on the serving side.

  • Server: Toggle Bouncer This is one of the preventive measures the server may take when the size of the group becomes uncomfortable for efficient communications. When this menu item is turned on, iStorm will put up a blunt bouncer against anyone who tries to join the group. (He will be immediately fired when the host deactivates it.) If one could foresee the problem, then the maximum number may be set in the Host panel at the beginning of the collaboration. Speaking of being hostile, please note that with iStorm 1.1 and later, we have introduced the password option with a bit of hesitation.

  • Server: Drop Selected The server may choose a group member in the list (accessed in the Chat drawer) and toss out. We hope it is with a good reason. One legitimate reason could be to remove the ghost client out of the way. A client becomes a ghost when he or she chooses the "Go Local" in panic for some reason. [Under normal circumstances, the member should have left the group by choosing "Disconnect" properly notifying everybody in the group.] The ghost status will remain so unless the server detects it and take care of it as part of its automatic patrol (see below). While it is better to keep clean account of everybody, this may not be a critical issue for most cases.
    • Hijacking the control of the document
    When the status button is red, if you press it once, the auxiliary window opens for you to while away. Pressing it twice more, it will send a polite private message to the current control holder, letting him/her know you want the control. Press three more times in a row, it will snatch the control from the current (and rightful) owner. Now, let us see what a brilliant idea you had to justify this!
    Fine tuning the connection timeout parameters
    In the iStorm Preferences, you will come across the Network section with various timeout and tolerance parameters. Finding the right parameters may be critical for a smooth collaboration especially when group members have a wide range of network quality. With some patience, you may be able to dramatically reduce need for "umbrellas" tweaking these parameters. We find that 120.0 seconds for Host timeout works for both LAN and internet connections. Client timeout may be between 5.0 and 10.0 seconds for fast LAN, maybe 30.0 seconds for internet. Poll interval for host may be as small as a few seconds, but give it at least 30 seconds, if you anticipate a laggard among your clients.

    While real time mode looks impressive, it may be better to switch it