
                           Spruce Design Goals
                              Draft Version

NOTE: This version of the Spruce Design Goals document has not yet been
subject to the level of editing and refinement as other Spruce materials;
this content has been placed here to be thought provoking, but not necessarily
of practical benefit at this early stage.


WHAT IS SPRUCE?
---------------

Spruce is an e-mail client (MUA).  E-mail clients perform duties predominantly
centering around the acts of: retrieving e-mail messages from remote servers,
sending outbound e-mail messages, storage of e-mail messages in accessible
form, and the reading of e-mail messages.


A CHANGE IN DIRECTION
---------------------

Also known as, Why do we still need Spruce when we have uber-clients like 
Helix Code's Evolution?

The design model and target for Spruce has changed as time has provided us
with ample need to rethink our goals.  There has been a birth of vastly
configurable mail client behemoths, supporting heaps of protocols, formats
and mail handling techniques.  These mail clients meet the needs of a very
broad audience, encompassing groupware features and a large number of
extensions beyond those found in mere mail clients.

Spruce is an e-mail client.  We do not seek to challenge or dethrone the
greatness of these larger client suites, but rather to provide a simple,
efficient, yet powerful e-mail client.  Supporting our goals, this design
document seeks to serve as a scope of work for the continuance of the 
Spruce mail client project.


SIMPLICITY IN DESIGN
--------------------

In comparison to most developmental software which has reached the level of
maturity and feature fullness of Spruce, the source design of Spruce is
considerably more simple.  Proper segragation of similar source sections,
clean formatting and a simple architecture developed around the use of glib
and gtk+ help to keep Spruce manageable and extensible.


LACK OF LIBRARY DEPENDENCE
--------------------------

The efforts currently underway for many projects, to utilize other libraries
in lieu of code duplication, are noble and desirable in most cases.  However,
in the case of Spruce, it is crucial for us to retain capability to remain
vastly independent of external libraries, except as needed for interfacing
with external programs (such as GPG/PGP), for GUI development (gtk+ and
glade), and for basic programming structures (glib, libc).  This lack of
significant dependencies allows the Spruce form factor to remain relatively
small (fewer libraries are required to use Spruce), which permits Spruce to
live in situations of limited resources.

Libraries used in conjunction with Spruce should be portable and be available
on a wide variety of platforms.  Care should be taken to document issues 
experienced with recent versions of libraries in common circulation, as 
well as to clearly define the minimum versions of these libraries which are
to be considered supportable in the compilation of Spruce.


RFC COMPLIANCE
--------------

Spruce strives for RFC compliance, for without this we have broken the
capability of our users to properly communicate with those who do not
use Spruce.  New code should not be admitted to Spruce if it does not meet
a basic level of conformance with the appropriate RFCs.  Existing code should
continue to be refined so as to add a higher level of conformance.  The basic
goal of a mail client should never be forgotten, send and receive mail so
as that the user may communicate properly with others.


USE OF BASIC, STANDARD FORMATS
------------------------------

Spruce shall strive to keep its own formats simple, yet managable.  Whereas
many projects have moved to XML for configuration, the level of complexity
held by Spruce should never exceed its current configuration mechanisms,
parsable text files; we should never be so complex as to need XML.

Mail should be stored in a format that allows it to be accessible with a
variety of existing tools; this format stands to be the popular mbox format,
used and supported by nearly all mail clients today.  This permits easy
transition to and from Spruce, as well as allowing the user to manipulate 
their Spruce-accessible mail using external tools, should they so desire.

Things such as addresses shall be stored in a very basic format.  Implementing
certain format standards, such as v.Card, is well beyond the scope of the
Spruce project.  Complexities shall be used only when necessary to provide
a basic level of mandatory standards compliance.


LIMITATIONS OF PROTOCOL SUPPORT, FORMAT SUPPORT
-----------------------------------------------

While Spruce does seek to be a powerful mail client, its complexity in
design, protocol support and format support shall be limited to those
which are considered to be most mainstream and standard.  Only the POP3,
IMAP and SMTP protocols and their variations shall be supported for mail 
transfer.  Limiting our development scope to these protocols allows us to
maintain an exceptionally high level of RFC compliance, through continued
refinement, as well as to limit the design complexity of Spruce.

People requiring extensive architectures with modular protocol support
and substantially larger protocol offerings should probably be looking to
the uber-clients, such as Evolution.  Spruce needs to stay lean to meet
its performance, size and maintainability requirements.  These limitations
-DO- limit the overall extensibility and capability of Spruce in comparison
to other products, however this is considered to be a desirable trait both
in terms of Spruce design and in producing a functional scope of work for the
Spruce project.


RICH CORE FEATURE OFFERING
--------------------------

Despite our pre-planned limitations in protocol and format support, most any
feature conforming to this design model, which may help to further extend
the rich feature offerings of Spruce, should be included.  Though with any
new feature, Spruce should continue to hold the utmost respect for continuity
of end-user service, ease of client use and functional performance.  (This may
be the most buzzword compliant paragraph in this document ;)

Simply put, new features should enhance Spruce, providing direct benefit to
the end user though not reducing the speed or making the interface excessively
complicated.  New features should be documented well.


PLATFORM INDEPENDENCE
---------------------

Spruce is designed to operate correctly on a wide array of platforms, including
most any Linux distribution and several of the BSDish platforms.  This 
platform independence which Spruce's source holds must be preserved as new
features are added.  
