README for Stupid little mailer, or Slime for short
version 0.11
by Lars Wirzenius, liw+slime@iki.fi


At the moment, this file is a random collection of notes for a new
mailer, code name Slime, which may or may not become a reality.

Note that Slime is very much alpha level code, and is quite fragile.
Be careful.

Installation and use

	0. Make sure you have Python (with Tkinter) and Mitch Chapman's
	   UITools package installed, and that Python can find UITools.
	   You can find a link to UITools on the Slime home page. Set
	   the PYTHONPATH environment variable to include the directory
	   where it is installed, if necessary.

	1. Unpack slime-<version>.tar.gz.
	
	2. Run "python ui.py".
	
	3. Play with it and watch your mail disappear.
	
	4. Report any bugs and ideas to author.
	
Background: Why a new mailer? What is missing from existing ones?

	I have not been satisfied by existing mailers, because
	they are not very suitable for large amounts of mail,
	do not support PGP or MIME well, don't have both a text
	and an X interface, are too slow, or are otherwise
	unsuitable. For example, I currently use Exmh, which
	is good, but slow, and lacks a text interface. Emacs
	has at least two fairly good mailers, but I won't use
	Emacs as my editor.
	
	I could find a fairly good one and improve that, but most
	good mailers are huge programs, and learning them well
	enough to improve them significantly is a large task.
	Some would also require me to learn a new language. For
	example, Exmh is written in Tcl/Tk, but I refuse to
	learn Tcl, since I don't like the language.

	Most of my requirements are simple enough to implement,
	it's just that no mailer happens to satisfy all of them.
	So, lured by the simplicity and hopefully complete
	supporting libraries of Python, I'm considering to
	write yet another mailer.
	
	That won't surprise my friends. After all, I wrote my
	own editor, as well. :)
	
Basic requirements

	* Must be simple to implement, since I can't afford to
	  spend lots of time on this.

	* Fast and efficient, within reason: if it feels fast enough,
	  it's fast enough, the point is not to optimize it for speed.
	  
	* The implementation must be modular, so that support for new
	  mail folder formats, mail retrieval and sending mechanisms,
	  user interfaces, and so on can be easily added.
	  
	  I will probably implement only stuff that I need myself,
	  but other people should have the possiblity to extend it.
	
	* Excellent PGP integration, including PGP/MIME, application/pgp,
	  plain PGP messages, key extraction, fetching missing keys,
	  sending keys as attachments or in mail bodies, and so on.
	  Users should be able to basically ignore PGP support, as long
	  as everything works (but the mailer should scream when a letter
	  has a bad signature, for example).
	  
	* Excellent MIME support, at least as good as Exmh. Attachments
	  and stuff should "just work". The mailer should show unknown
	  content types as well as it can, e.g., by showing all printable
	  characters, at least as an option.
	  
	* Must work for huge amounts of e-mail correspondence, on the order of
	  thousands per day (e.g., via many large-volume mailing lists).
	  This means supporting arbitrary numbers of "inbox" folders
	  (including many APOP or IMAP folders) at the same time, doing
	  real message threading, supporting archiving and full text
	  searches, finding addresses easily, and keeping track of
	  messages that need to be processed still (this is different
	  from being unread).
	
	* The user interface should be simple to learn and use. Typical
	  operations should be a single mouse click or key press. All
	  dangerous operations (including deletion of mail) should be
	  difficult to invoke by accident. Going through unread
	  mail should happen just by pressing a space bar,
	  even if the mail is in many folders.

	* Configuration must be easy (not just via editing a text file)
	  for users. This means something like the Pine configuration
	  menu. Configuration should not be necessary to use the software,
	  however.
	  
	* It must be possible to view any number of folders and messages
	  at once, and to edit any number of replies at once. A draft
	  folder a la MH must be supported.
	  
	* Must be compatible with other mailers, i.e., not require that
	  users convert their folders to a particular folder format.
	  This makes it possible to use Slime concurrently with another
	  mailer (important during development and when users try it out).
	  
	* Maybe: virtual folders, annotations, links between messages.
	  But these will probably be too much work to implement.
	  
Design

	Slime will be implemented in Python, if at all, and
	will consist of some number of classes that implement
	various features. Some of these classes will be abstract,
	they will just define an interface to a large number
	of similar objects. For example, there will be some
	kind of Folder class, which defines the interface to a
	mail folder, and different subclasses will implement
	the interface to allow access to mailbox files, MH
	directories, Maildir directories, IMAP folders, and
	so on. The rest of the program will then not need to
	care what the actual folder format is.

Folder hierarchy

	A folder collection, such as ~/Mail for MH, or ~/mail for
	Pine, is a folder, with no messages, just subfolders.
	This way the folders in a collection form a natural
	hierarchy.
	
	There is a SlimeFolderRoot class that lists all
	folder collections. The user may add and remove folder
	collections, represented as subfolders (of course), using
	some sort of menu selection. An instance of this class
	is made persistent (loaded at startup, saved at exit).

Status header

	The following is gleaned from mutt sources:
	
		D = deleted
		* = flagged
		r = replied
		- = read
		O = old
		N = new?
		
	And only one character?

	Unknown status chars:
	
		R
		A


Redesigned abstract classes

	module is slime.py

	Exception:
	error = 'slime.error'

	def thread_messages(list_of_messages):
	def find_folder(folder_name):

	class Folder:
		def __init__(self, full_name):

		def get_full_name(self):
		def get_short_name(self):

		def delete(self):
		
		def lock(self):
		def unlock(self):

		def scan_messages(self, smart=1):
		def list_messages(self, choose=None):
		def create_message(self, file):
		def copy_message(self, msg):
		def move_message(self, msg):

		def scan_subfolders(self, smart=1):
		def list_subfolders(self):
		def scan_subfolders(self):
		def create_subfolder(self, relative_name):

		def is_clean(self):
		def make_dirty(self):
		def make_clean(self):
		def commit(self):
		
	class Message:
		def __init__(self, folder):

		def forget_headers(self):
		def read_headers(self):
		
		def is_dirty(self):
		def make_clean(self):

		def set_status(self, new_status):
		def get_status(self):
		def has_status(self, status):
		def give_status(self, status):
		def remove_status(self, status):
		
		def set_contents(self, file):
		
		def get_file(self):
		
		# union of the interfaces of rfc822.Message, mimetools.Message,
		# and mhlib.Message.
		...
		# or maybe there is a better interface that could be
		# implemented by scratch to avoid using multiple layers?

	def test():
		- open folder
		- count # of messages
		- list some of the headers of each message
		- thread messages
		- delete message
		- add message
		- copy/move message to another folder (to each folder type)
		- have N processes try to modify the folder at once
		  (some create messages, others delete them, some just
		  read the folder)


	- communication between different windows?

	class MessageWindow:
		def __init__(self):
		def set(self, message):

	class MessageListWindow:
		def __init__(self):
		def set(self, list_of_messages):
		def update(self, message):
	
	class FolderListWindow:
		def __init__(self):
		def set(self, list_of_folders):
		def update(self, folder):