Remove some obsolete documentation.

These date back to Evolution 1.x era or perhaps earlier.

1 files changed, 0 insertions, 201 deletions

diff --git a/doc/Design b/doc/Design
deleted file mode 100644
index 3e8f9bea3c..0000000000
--- a/doc/Design
+++ /dev/null
@@ -1,201 +0,0 @@
-
-The Evolution Project specification
-Miguel de Icaza.
-
-
-* Introduction
-
-	Evolution is a project aiming at providing the free software
-	community with a professional, high-quality tool for managing
-	mail, appointments, tasks and other personal information
-	tools.  
-
-	We want to make Evolution a system that addresses our needs
-	(the free software development community) and we believe that
-	by addressing our needs, we will provide a system that will
-	scale in the years to come for other users that are just
-	starting to use computers and the internet.
-
-	The main objectives of Evolution are to provide these powerful
-	features, and to make the user interface as pretty and
-	polished as possible.
-
-	Evolution is a GNOME application and a number of auxiliary
-	CORBA servers that act as the storage backends. 
-
-	Evolution will copy the best user interface bits and the best
-	ideas and features found on contemporary groupware systems.
-
-* Evolution internals.
-
-	Evolution can store its information locally (files for mail,
-	calendar and address book) or on a remote server (imap/pop,
-	cap, ldap).  
-
-	Given the importance of syncing in this modern PDA world,
-	the Evolution GUI acts as a client to the data repository.
-	The data repository is a GUI-less CORBA server called Wombat.
-
-	Wombat provides a unified access system to the calendar and
-	addressbook data (doing mail is a bit hard, so we are leaving
-	this as a TODO item for now).
-
-	Wombat's CORBA interfaces are notifier-based.  This means that
-	CORBA requests sent to Wombat do not return values
-	inmediately, but rather than for Wombat requests the user has
-	to provide a CORBA object that will be notified of what
-	happened.
-
-	Yes, that sounds hairy.  It is actually pretty simple.  It
-	basically means that you submit requests to Wombat, and a
-	callback is invoked in your code when the request has been
-	carried away. 
-
-	This enables a Palm to sync to the repository without having
-	the GUI for Evolution running.  It also means that volunteers
-	will be able to write text-based and web-based versions of
-	Evolution (not me though :-).
-
-* Evolution as a platform
-
-	Evolution is more than a client for managing the above
-	information: Evolution is a platform for building groupware
-	applications that use the above components to get their work done.
-
-	To achieve this Evolution is designed to be scriptable, and it
-	exports its internals through CORBA/Bonobo.  It is implemented
-	as a collection of Bonobo containers and Bonobo components.
-
-	There is a clean separation between the views (the user
-	interface) and the model (the view).  The views that we are
-	writing are GNOME based, and they talk to the Wombat CORBA
-	server.
-
-	Wombat takes care of notifications to the various clients for
-	the data. 
-
-* The overall organization
-
-	A bar similar to outlook provides shortcuts for accessing the
-	various resources managed by Evolution: mail folders,
-	contacts, tasks, journal entries, notes, messages and other
-	user-defined destinations. 
-
-* User interface widgets
-
-** The ETable package
-
-	This package provides a way of displaying and editing tables.
-
-	Tables are displayed based on a TableColumn definition that
-	defines the layout used for the display.  Table Columns can be
-	nested, and the package does grouping of information displayed
-	according to the criteria defined there.
-
-	This is used in multiple places throughout evolution: it is
-	used for the Mail summary display, for the TODO display and
-	TODO new data entry and for the address book.
-
-	Nesting in the address book can be performed on various
-	fields.  For example, a first level of nesting could be
-	"Company" and a second level would be "Country" the result is
-	a 2-level tree that can be collapsed expanded and contains the
-	information sorted/grouped by those two criteria.
-
-	The user interface for this will be copied from Outlook: the
-	possibility of adding and removing fields with drag and drop
-	as well as grouping using drag and drop.
-
-* The Mail system
-
-** The Mail sources
-
-	The mail system will support 4 sources of mail:
-
-		POP3 (transfer to a local file).
-		IMAP
-		Local mbox format in $MAIL.
-		Local mbox format that have other delivery points.
-
-	On top of that, it will be possible to browse existing mbox
-	archives (and possibly other formats in the future, like
-	Mailbox and Maildir).
-
-** Storing the mail
-
-	Mail that gets incorporated into the system is stored in mbox
-	format, and summary files are provided for quick access to the
-	files.  No modifications to the file on disk is performed (I
-	am not quite sure about this, perhaps we want to add the
-	status flags and some method for adding metadata to the mail).
-
-	Summary files are rebuilt on demand or rebuild if the mbox
-	file and the summary file have got out of sync.
-
-	A Metadata system that will enable us to attach information to
-	a message will have to be designed and implemented (enabling
-	users to add annotations to mails, and special keywords and
-	flags in a per-message fashion).
-
-** Folders
-
-	Michael Zucchi is working on a system that will let users
-	easily define rules for splitting their incoming mail into
-	physical folders.  
-
-	A further refinement to Folders are Virtual Folders.  This
-	basically provides a powerful search and viewing facility for
-	mail.  It works like this: when a mail is "incorporated" into
-	Evolution it is scanned and indexed.
-
-	Then users can enter queries into Evolution that will search
-	the entire database of messages.	
-
-** Virtual folders
-
-	Virtual folders will enable users to read/browse their mail in
-	new ways: by specifying search criterias, these folders will
-	contain messages that match the criteria given.  
-
-	There is more information about this in the libcamel
-	directory. 
-
-	We will index all headers from a message, and possible the
-	contents of messages and keep those on a separate file, to
-	enable users to query their mail database.
-
-** Mail summary display
-
-	The summary will be displayed using the ETable package, to
-	enable users to add a number of sorting criteria and various
-	display methods for the summary view.
-
-	The Outlook methods for displaying will be present on the
-	system.
-
-	Message threading will be supported in Evolution.
-
-** Message display engine
-
-	We are going to be using a combination of
-	libcamel/limime/libjamie to parse messages and render them
-	into an HTML buffer.
-
-* The HTML engine
-
-	The GtkHTML engine will be used to display messages, and will
-	be extended to support a number of features that we require:
-	internal handling of characters will be based on Unicode
-
-* The message composer
-
-	Regular features found in composers will be added: connecting
-	the composer to the address book, support for drag and drop
-	for including attachments, editing the message, archiving
-	drafts and archiving messages sent.
-
-	Ettore has been working on adding editing support to the
-	GtkHTML and he is working currently on a Bonobo component that
-	will provide a ready-to-use Bonobo control for embedding into
-	other applications.
-