PostOfficeDoc.tioga
Doug Terry, July 30, 1993 3:45 pm PDT
POSTOFFICE
CEDAR 10.1 —
PostOffice
Doug Terry
© Copyright 1992 Xerox Corporation. All rights reserved.
Abstract: Generically, PostOffice is a RPC service that permits ParcTabs (and other clients potentially) to access messages managed by a Cedar-based electronic mail reader. WalnutPostOffice is a specific instantiation of this service for the Walnut mail reader (aka WallTapestry).
XEROX  Xerox Corporation
   Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, California 94304
1. Introduction
The PostOffice protocol has been defined in order to permit ParcTabs and other non-Cedar programs to access messages managed by a Cedar-based electronic mail reader, such as WallTapestry. This is a fairly simple SUN RPC protocol that allows clients to check for new mail, retrieve messages, mark messages as deleted, list folders, etc.
To read your mail on a ParcTab, you must: (1) run WallTapestry in a Cedar world on your machine, i.e. type "WallTapestry" (2) run the Walnut PostOffice Server by typing "WalnutPostOfficeServer", and (3) pick up your ParcTab and run the mail agent by clicking on the icon that looks like a mail letter (currently on the top row of the main menu, second from the right). From your ParcTab, you will now be able to read those messages in your Active message set that have been assigned a priority above some threshold (if you don't use WallTapestry's appraisers, you will get the whole message set by default); messages are presented in priority order. You can continue to use WallTapestry concurrently with using the ParcTab mail agent.
The rest of this document describes the PostOffice protocol and the Walnut PostOffice Server in more detail.
2. The PostOffice protocol
The RPC protocol is based on the notion of sessions. During each session, the client has access to a fixed set of messages. This set is specified when the session is started by a list of properties that must be held by the messages in the session (this can be thought of as a query over the message database). Messages within a session are accessed by a unique ID, a number in the range from 0 to one less than the number of messages selected. The ordering of messages in a session, i.e. the assignment of messages to IDs, is also specified when the session is started. The RPC protocol assumes that only a single session exists at any given time; it does not support multiple clients or multiple sessions per client.
See TabPostOffice.x for details.
3. WalnutPostOffice
WalnutPostOfficeServer implements the server side of the PostOffice protocol. It provides access to a WallTapestry mail database. The PostOffice protocol permits clients to send a selection predicate when they start a session. This predicate can specify which messages are to be selected from which messages sets. The current WalnutPostOfficeServer understands a variety of selection predicates involving one or more message sets and relational operators on message priorities.
The only known client for talking to this service is the ParcTab mail agent. It permits a WallTapestry user to read (some of) their mail from a ParcTab. The current ParcTab client always sends an empty selection predicate. WalnutPostOfficeServer interprets this to mean that the client wants messages from the "active" message set(s) that are above some priority (see the user profile entries below).
The following user profile entries customize the behavior of the Walnut PostOffice Server; the values given below are the default values, which should work fine for most users:
WalnutPostOffice.ActiveMessageSets: Active
-- The message set(s) from which messages are to be retrieved.
WalnutPostOffice.PriorityThreshold: 50
-- Only messages at or above this priority are retrieved.
WalnutPostOffice.LengthThreshold: 5000
-- Only the body of messages that are shorter than this length are returned; others appear in the message summary, but their text is simply "message too long".
4. Other PostOffice servers
Currently, WalnutPostOffice is the only PostOffice server for the Cedar world. One could imagine building such a server for BlackCherry or Peanut or any other Cedar-based mail system that might exist.
In the UNIX world, a PostOffice server exists for reading mail that resides in a /usr/spool/mail file. See the ParcTab team for details.
5. Known bugs and limitations
RPC protocol
* TabPostOffice.x should really be called simply PostOffice.x since it is not specific to the ParcTab.
* The PostOffice protocol needs to be better documented since TabPostOffice.x does not tell the whole story. In particular, the semantics of sessions as well as what operations are allowed at certain times and how to interpret their results is not clear from the ".x" file.
* Someday, the PostOffice protocol should probably be replaced with a more "standard" protocol such as IMAP or POP. The current protocol was designed by Maria Ebling and Doug Terry as an expedient during the summer of 1992.
Walnut Post Office server
* Starting a mail reading session, i.e. retrieving the list of selected messages, is too slow (often 10-20 seconds for an Active message set of 100-200 messages). This is because Walnut must enumerate the whole message set and perhaps even parse each message to determine which messages match the selection criteria. Keep your active message set small.
ParcTab email application
Here are some known bugs in the ParcTab mail agent (listed here for lack of a better place and because you might run into them):
* Occasional painting problems have been observed on the ParcTab when running this application, i.e. sometimes a screen only gets half painted or portions of different screens appear together.
* When the ParcTab email application starts up, it calls StartSession twice in a row. This causes it to be twice as slow as necessary.
* The ParcTab email application calls StartSession whenever it returns to its top-level menu. This means that it calls StartSession when you say "bye" to the message summary display, which is not what you want if you are exiting the program. It also means that you can't quickly exit the program and then return later to continue reading mail.
The following limitations are not in WalnutPostOfficeServerImpl, per se, but instead arise due to limitations in the ParcTab mail agent:
* Users should be able to retreive messages from more than one message set, e.g. from something other than the Active message set.
* Users should be able to retreive messages that match a selection criteria other than a priority threshold.
* Users should be able to delete messages, move them into other message sets, etc.