Software: Apache/2.0.54 (Unix) mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.54 OpenSSL/0.9.7l DAV/2 FrontPage/5.0.2.2635 PHP/4.4.0 mod_gzip/2.0.26.1a 

uname -a: Linux snow.he.net 4.4.276-v2-mono-1 #1 SMP Wed Jul 21 11:21:17 PDT 2021 i686 

uid=99(nobody) gid=98(nobody) groups=98(nobody) 

Safe-mode: OFF (not secure)

/usr/doc/pine4.64/tech-notes/   drwxr-xr-x
Free 318.35 GB of 458.09 GB (69.5%)
                            Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    

Viewing file:     introduction.html (4.16 KB)      -rw-r--r--

Introduction

Design Goals

- 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

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.