From 6561e49374018bd4828de2637df5250b3dba9ba6 Mon Sep 17 00:00:00 2001 From: nobody Date: Tue, 9 Dec 2003 01:57:09 +0000 Subject: This commit was manufactured by cvs2svn to create tag 'GNOME_SYSTEM_MONITOR_2_6_0'. svn path=/tags/GNOME_SYSTEM_MONITOR_2_6_0/; revision=23789 --- doc/white-papers/mail/camel.sgml | 356 --------------------------------------- doc/white-papers/mail/ibex.sgml | 158 ----------------- 2 files changed, 514 deletions(-) delete mode 100644 doc/white-papers/mail/camel.sgml delete mode 100644 doc/white-papers/mail/ibex.sgml (limited to 'doc/white-papers/mail') diff --git a/doc/white-papers/mail/camel.sgml b/doc/white-papers/mail/camel.sgml deleted file mode 100644 index 5f5ea27a98..0000000000 --- a/doc/white-papers/mail/camel.sgml +++ /dev/null @@ -1,356 +0,0 @@ -Evolution"> - -]> - -
- - - The &Camel; Messaging Library - - - - Jeffrey - Stedfast - -
- fejj@helixcode.com -
- - - - - Michael - Zucchi - -
- notzed@helixcode.com -
- - - - - Dan - Winship - -
- danw@helixcode.com -
- - - - - Bertrand - Guiheneuf - -
- bertrand@helixcode.com -
- - - - - - 2000, 2001 - Ximian, Inc. - - - - - - Introduction - - - &Camel; is a generic messaging library. It is being used as the - back end for the mail component of &Evolution;. The name - "&Camel;" is an acronym; it refers to the fact that the - library is capable of going several days without food or water. - It means : Camel's Acronym Makes Everyone Laugh. - - - - &Camel;'s initial design is heavily based on Sun's - JavaMail API. It uses the Gtk+ object - system, and many of its classes are direct analags of JavaMail - classes. Its design has also been influenced by the features of - IMAP, and the limitations of the standard UNIX mbox mail store, - which set some of the boundaries on its requirements and - extensibility. - - - - &Camel; sees all message repositories as stores containing - folders. These folders in turn contain the messages the client - actually accesses. The use of such a unified interface allows - the client applications to be very extensible. &Camel; includes - an external provider mechanism which allows applications to - dynamically load and use protocols which were not available when - the application was initially written. - - - - The abstract store/folder mechanism is a powerful and versatile - way of accessing messages. No particular asumptions are made on - the client side, thus allowing new ways of managing the - messages. For example, the messages stored in the folders don't - necessarily have to share some common physical location. The - folder can be a purely virtual folder, containing only - references to the actual messages. This is used by the "vFolder" - provider, which allows you select messages meeting particular - criteria and deal with them as a group. - - - - In addition to these possibilities, &Camel; has full MIME - support. &Camel; MIME messages are lightweight objects - representing the MIME skeleton of the actual message. The data - contained in the subparts are never stored in memory except when - they are actually needed. The application, when accessing the - various MIME objects contained in the message (text parts, - attachments, embedded binary objects ...) asks &Camel; for a - stream that it can read data from. This scheme is particularly - useful with the IMAP provider. IMAP has strong MIME support - built-in, which allows &Camel; to download only the parts of - messages that it actually needs: attachments need not be - downloaded until they are viewed, and unnecessary - "multipart/alternative" parts will never be read off the server. - - - - - Overview - - - - - To begin using &Camel;, an application first creates subclassed - CamelSession object. This object is used - to store application defaults, and to coordinate communication - between providers and the application. - - - - A CamelProvider is a dynamically-loadable - module that provides functionality associated with a specific - service. Examples of providers are POP, IMAP and SMTP. Providers - include subclasses of the various other &Camel; classes for - accessing and manipulating messages. - - - - CamelService is an abstract class for - describing a connection to a local or remote service. It - currently has two subclasses: CamelStore, - for services that store messages (such as IMAP servers and mbox - files), and CamelTransport, for services - that deliver messages (such as SMTP or a local MTA). A provider - could also be both a store and a transport, as in the case of - NNTP. - - - - A CamelStore contains some number of - CamelFolder objects, which in turn - contain messages. A CamelFolder provides - a CamelFolderSummary object, which - includes details about the subject, date, and sender of each - message in the folder. The folder also includes the messages - themselves, as subclasses of CamelMedium. - - - - Email messages are represented by the - CamelMimeMessage class, a subclass of - CamelMedium. This class includes - operations for accessing RFC822 and MIME headers, accessing - subparts of MIME messages, encoding and decoding Base64 and - Quoted-Printable, etc. - - - - CamelTransport includes methods for - delivering messages. While the abstract - CamelTransport::send method takes a - CamelMedium, its subclasses may only be - able to deliver messages of specific - CamelMedium subclasses. For instance, - CamelSendmailTransport requires a - CamelMimeMessage, because it needs a - message that includes a "To:" header. A hypothetical - CamelNNTPTransport would need a - CamelNewsMessage, which would have a - "Newsgroups:" header. - - - - The content of messages are referred to using - CamelStream and its subclasses. In the - case of an mbox-based store, the - CamelStream would abstract the operation - of reading the correct section of the mbox file. For IMAP, - reading off the CamelStream might result - in commands being issued to the remote IMAP server and data - being read off a socket. - - - - The final major class in &Camel; is - CamelException, which is used to - propagate information about errors. Many methods take a - CamelException as an argument, which the - caller can then check if an error occurs. It includes both a - numeric error code which can be interpreted by the program, and - a text error message that can be displayed to the user. - - - - - Major Subcomponents - - - The Message Store - - - A CamelStore inherits the ability to - connect and authenticate to a service from its parent class, - CamelService. It then adds the ability - to retrieve folders. A store must contain at least one folder, - which can be retrieved with - CamelStore::get_default_folder. There are - also methods to retrieve the "top-level" folder (for - hieararchical stores), and to retrieve an arbitrary folder by - name. - - - - All CamelFolders must implement certain - core operations, most notably generating a summary and - retrieving and deleting messages. A - CamelFolder must assign a permanently - unique identifier to each message it contains. Messages can - then be retrieved via - CamelFolder::get_message. - - - - Folders must also implement the - get_parent_folder and - list_subfolders methods. For stores that - don't allow multiple folders, they would return NULL and an - empty list, respectively. Stores that do allow multiple - folders will also define methods for creating and deleting - folders, and for moving messages between them (assuming the - folders are writable). - - - - Folders that support searching can define the - search_by_expression method. For mbox - folders, this is implemented by indexing the messages with the - ibex library and using that to search them later. For IMAP - folders, this uses the IMAP SEARCH command. Other folder types - might not be able to implement this functionality, in which - case users would not be able to do full-content searches on - them. - - - - - Messages - - - As mentioned before, messages are represented by subclasses of - CamelMedium. - CamelMedium itself is a subclass of - CamelDataWrapper, a generic class for - connecting a typed data source to a data sink. - CamelMedium adds the concept of message - headers versus message body. - (CamelDataWrapper has one other - important subclass, CamelMultipart, - which is used to provide separate access to the multiple - independent parts of a multipart MIME type.) - CamelMedium's subclasses provide more - specialized handling of various headers: - CamelMimePart adds special handling for - the &ldquot;Content-*&rdquot; headers in MIME messages, and - its subclass CamelMimeMessage adds - handling for the RFC822 headers. - - - - - - Consider a message with two parts: a text part (in both plain - text and HTML), and an attached image: - - - - From: Dan Winship <danw@helixcode.com> - To: Matt Loper <matt@helixcode.com> - Subject: the Camel white paper - MIME-Version: 1.0 - Content-Type: multipart/mixed; - boundary="jhTYrnsRrdhDFGa" - - This is a multi-part message in MIME format. - --jhTYrnsRrdhDFGa - Content-Type: multipart/alternative; - boundary="sFSenbAFDSgDfg" - - --sFSenbAFDSgDfg - Content-Type: text/plain - - Hey, Matt - - Check out this graphic... - - -- Dan - - --sFSenbAFDSgDfg - Content-Type: text/html - - Hey, Matt<br> - <br> - Check out this graphic...<br> - <br> - -- Dan<br> - <br> - --sFSenbAFDSgDfg-- - - --jhTYrnsRrdhDFGa - Content-Type: image/png - Content-Transfer-Encoding: base64 - - F4JLw0ORrkRa8AwAMQJLAaI3UDIGsco9RAaB92... - --jhTYrnsRrdhDFGa-- - - - - In &Camel;, this would be represented as follows: - - - - - - - Streams - - - Streams are a generic data transport layer. Two basic stream - classes are CamelStreamFs, for - reading and writing files, and - CamelStreamMem, for reading from and - writing to objects that are already in memory. - - - - Streams can also be filtered. So a CamelMimePart - containing base64-encoded data can filter its output through - CamelMimeFilterBasic. Other parts of the application that want - to read its data will never need to even realize that the - original data was encoded. - - - -
diff --git a/doc/white-papers/mail/ibex.sgml b/doc/white-papers/mail/ibex.sgml deleted file mode 100644 index dcb8f5ca4b..0000000000 --- a/doc/white-papers/mail/ibex.sgml +++ /dev/null @@ -1,158 +0,0 @@ -Evolution"> - - -]> - -
- - - Ibex: an Indexing System - - - - Dan - Winship - -
- danw@helixcode.com -
- - - - - - 2000 - Helix Code, Inc. - - - - - - Introduction - - - &Ibex; is a library for text indexing. It is being used by - &Camel; to allow it to quickly search locally-stored messages, - either because the user is looking for a specific piece of text, - or because the application is contructing a vFolder or filtering - incoming mail. - - - - - Design Goals and Requirements for Ibex - - - The design of &Ibex; is based on a number of requirements. - - - - - First, obviously, it must be fast. In particular, searching - the index must be appreciably faster than searching through - the messages themselves, and constructing and maintaining - the index must not take a noticeable amount of time. - - - - - - The indexes must not take up too much space. Many users have - limited filesystem quotas on the systems where they read - their mail, and even users who read mail on private machines - have to worry about running out of space on their disks. The - indexes should be able to do their job without taking up so - much space that the user decides he would be better off - without them. - - - - Another aspect of this problem is that the system as a whole - must be clever about what it does and does not index: - accidentally indexing a "text" mail message containing - uuencoded, BinHexed, or PGP-encrypted data will drastically - affect the size of the index file. Either the caller or the - indexer itself has to avoid trying to index these sorts of - things. - - - - - - The indexing system must allow data to be added to the index - incrementally, so that new messages can be added to the - index (and deleted messages can be removed from it) without - having to re-scan all existing messages. - - - - - - It must allow the calling application to explain the - structure of the data however it wants to, rather than - requiring that the unit of indexing be individual files. - This way, &Camel; can index a single mbox-format file and - treat it as multiple messages. - - - - - - It must support non-ASCII text, given that many people send - and receive non-English email, and even people who only - speak English may receive email from people whose names - cannot be written in the US-ASCII character set. - - - - - - While there are a number of existing indexing systems, none of - them met all (or even most) of our requirements. - - - - - The Implementation - - - &Ibex; is still young, and many of the details of the current - implementation are not yet finalized. - - - - With the current index file format, 13 megabytes of Info files - can be indexed into a 371 kilobyte index file—a bit under - 3% of the original size. This is reasonable, but making it - smaller would be nice. (The file format includes some simple - compression, but gzip can compress an - index file to about half its size, so we can clearly do better.) - - - - The implementation has been profiled and optimized for speed to - some degree. But, it has so far only been run on a 500MHz - Pentium III system with very fast disks, so we have no solid - benchmarks. - - - - Further optimization (of both the file format and the in-memory - data structures) awaits seeing how the library is most easily - used by &Evolution;: if the indexes are likely to be kept in - memory for long periods of time, the in-memory data structures - need to be kept small, but the reading and writing operations - can be slow. On the other hand, if the indexes will only be - opened when they are needed, reading and writing must be fast, - and memory usage is less critical. - - - - Of course, to be useful for other applications that have - indexing needs, the library should provide several options, so - that each application can use the library in the way that is - most suited for its needs. - - -
-- cgit v1.2.3