diff options
Diffstat (limited to 'README')
| -rw-r--r-- | README | 250 |
1 files changed, 250 insertions, 0 deletions
@@ -0,0 +1,250 @@ +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): |