                                  Introduction

Design Goals

   Throughout Pine development, we have had to strike a balance between
   the need to include features which advanced users require and the need
   to keep things simple for beginning users. To strike this balance, we
   have tried to adhere to these design principles:

          - The model presented to the user has to be simple and clear.
          Underlying system operation is hidden as much as possible.
          - It's better to have a few easily understood commands that can
          be repeated than to have some more sophisticated command that
          will do the job all at once.
          - Whenever the user has to select a command, file name, address,
          etc., the user should be given (or can get) a menu from which to
          make the selection. Menus need to be complete, small, organized
          and well thought out.
          - Pine must provide immediate feedback for the user with each
          operation.
          - Pine must be very tolerant of user errors. Any time a user is
          about to perform an irreversible act (send a message, expunge
          messages from a folder), Pine should ask for confirmation.
          - Users should be able to learn by exploration without fear of
          doing anything wrong. This is an important feature so the user
          can get started quickly without reading any manuals and so fewer
          manuals are required.
          - The core set of Pine functions should be kept to a minimum so
          new users don't feel "lost" in seemingly extraneous commands and
          concepts.

   Just as there were goals relating to the look and feel of Pine, there
   were equally important goals having to do with Pine's structure-the
   things that users never see but still rely on every time they use Pine.
   While Pine can be used as a stand-alone mail user agent, one of its
   strongest assets is its use of the Internet Message Access Protocol
   (IMAP) for accessing remote email folders. In addition, Pine was one of
   the first programs to support the Multipurpose Internet Mail Extensions
   (MIME) specification. With MIME, Pine users can reliably send any
   binary file to any other person on the Internet who uses a MIME
   compliant email program.

   The decision to use IMAP and MIME reflects the importance of
   interoperability, standardization and robustness in Pine. As you work
   with Pine more, you will see other features which reflect the same
   values. For example, Pine enforces strict compliance with RFC 822,
   implements a strong mail folder locking mechanism and verifies a
   process before overwriting any files (e.g. addressbook, expunging
   messages).

Pine Components

   If you have picked up the Pine distribution, then you already know that
   Pine comes in a few different pieces. They are:

   Pine
          The main code from which the Pine program is compiled.
   Pico
          Pico is the name for the Pine composer. The Pico code is used in
          two ways: (1) it is compiled on its own to be a stand-alone
          editor and, (2) it is compiled as a library for Pine to support
          composition of messages within Pine. Pico is Pine's internal
          editor invoked when users need to fill in header lines or type
          the text of an email message.
   Imap
          An API for IMAP. Includes the C-Client library, which is
          compiled into Pine, and the IMAP server IMAPd. C-Client
          implements the IMAP protocol and also negotiates all access
          between Pine and the mail folders it operates on, even if the
          folders are local. The C-Client routines are used for email
          folder parsing and interpreting MIME messages. IMAPd is a
          separate server that handles IMAP connections from any
          IMAP-compliant email program. When Pine accesses a remote
          mailbox, the Pine program is the IMAP client and the IMAPd
          program is the IMAP server.
