Pachyderm: Bandwidth Tolerance

Some effects of this requirement aren't directly visible to the user. For example, we use concurrency in the Java applet to hide network delays from the user. When the user adds or removes a label (the analog of refiling a message in folder-based systems), the action is actually just enqueued in the Java applet, and an asynchronous thread performs the actual transaction with the server. The user meanwhile can get on with other work. Further, if the asynchronous thread falls behind, it tries to perform multiple label updates in a single HTTP transaction, the better to amortize the network delays.

Similarly, when the user clicks on a message in the list resulting from a query, indicating that he wants the message displayed, the actual display is performed by an asynchronous thread so that the user is free to perform other actions. If the other actions result in making the message display unnecessary (e.g. he asks for a different message to be displayed), the thread quietly desists.

The most visible technique for toleration of low bandwidth comes in the display of structured messages. Pachyderm understands most email structuring conventions, including MIME, uuencode, and even just appended PostScript files. In all these cases, when the user asks to see the message, Pachyderm initially transfers just the top-level covering note to the client computer. The top-level note contains hot-links for the remaining parts of the message. If (and only if) the user decides that he actually wants to deal with the attachment (e.g. a PowerPoint presentation, or a JPEG image, or a PostScript file), then he clicks on the link and the attachment is transferred to his browser.