Camel - A mail access library
This is a start page for documentation on the Camel library, which extends upon the information provided in the API documentation.
Camel.Address, rfc822 and newsgroup address parsers and encoders.
Camel.DataWrapper, the entire structured-mime-message interface, used to access and create messages.
Camel.Index, camel's context indexing interface and implementation details.
Camel.MimeFilter, what it is, how to use it, what the multitude of existing filters do.
Camel.MimeParser, the core mail parser object in all its gory details.
Camel.MimeUtils, various mail and mime related utilities.
Camel.Misc, various other miscellaneous utilities and helper functions.
Camel.Object, describes all you never wanted to know about Camel's object system.
Camel.Operation, explains how the progress reporting and cancellation object is used.
Camel.Stream, covers streams - files, sockets, etc.
Camel.URL, URI decoder/encoding object.
And the libcamel-provider objects, which are used or implemented by custom backends.
Camel.CipherContext, provides encryption and signature interfaces.
Camel.Digest, a virtual folder and store for representing multipart/digest messages as folders.
Camel.FilterDriver, filtering engine.
Camel.Folder, the message storage and retrieval interface.
Camel.FolderSummary, the message information storage and retrieval class.
Camel.FolderThread, message threading helper.
Camel.Offline offlinable storage backend interfaces.
Camel.Provider, the plugin interface for adding alternative backends.
Camel.ProviderMisc, various other miscellaneous helper functions in libcamel-provider.
Camel.Search, information on the implementation and expressions used for filtering and searching.
Camel.SASL, secure authentication drivers.
Camel.Service, the base class for mail access, storage and sending.
Camel.Session, the main application context object defined by the client.
Camel.Store, represents connections and folder listing for mail storage.
Camel.StoreSummary, helper class for tracking folder lists.
Camel.Stream, socket streams.
Camel.Transport, the mail sending base class.
Camel.VFolder, the virtual folder store and folder classes.
In addition, there has been a significant amount of work on the 'notzed-disksummary-branch' in gnome cvs. This is covered in the CamelDS set of pages.
This section lists some notes about the various providers at various levels of details. As usual, consult the source for the most up to date and hard information.
Camel.Local, the local provider, for mbox, mh, and Maildir mail storage.
Camel.IMAP, the 'original' imap provider, worts and all.
Camel.POP3, the POP3 backend.
Camel.NNTP, the news backend.
And the transports (for sending mail)
Camel.SMTP, for sending with SMTP.
Camel.Sendmail, for sending with sendmail.
Numerous people and a few organisations have contributed to what now constitutes Camel, but some of the major contributors are listed below in approximately chronological order.
Nat and Miguel
- Who started Ximian (Helix Code), without which the project might never had so many resources supplied to it.
Kicked off the project in the first place, to write a re-usable, free, mail library, based roughly on the JavaMail API design.
- One of the early core developers and longest consistent contributor (over 5 years). Worked on everything from the MIME parser, multi-threading, indexing, searching, filtering, performance, local mail storage, rfc compliance, interoperability, to the initial cut of this documentation.
- Another of the early core developers. Primarily worked on the original IMAP implementation; although sworn at heavily is still in operation, offline mode, and the Exchange Connector (which implements another Camel provider), amongst plenty of bug fixes.
- The second longest consistent contributor (almost 5 years). IMAP, POP, SMTP backends, lots of rfc compliance work, filtering work, SASL authentication, and many many other items, both large and small.
- Which continues to fund the core developers.
The Gnome I18N team
- Who have provided numerous translations.
The Novell Bangalore team
- Who should be named by name, Partha, Shreyas, Vivek, Harish, Sankar and others. Mainly groupwise work so far, but also general debugging and features too. The new maintainers post 9/2005.
- For anyone left out; contributions from both internal and external developers who were not core developers on the library, or whom I unfortunately forgot right now.