diff options
Diffstat (limited to 'devel-docs/misc')
| -rw-r--r-- | devel-docs/misc/ref_and_id_proposition.txt | 237 |
1 files changed, 0 insertions, 237 deletions
diff --git a/devel-docs/misc/ref_and_id_proposition.txt b/devel-docs/misc/ref_and_id_proposition.txt deleted file mode 100644 index 2127b45a57..0000000000 --- a/devel-docs/misc/ref_and_id_proposition.txt +++ /dev/null @@ -1,237 +0,0 @@ -Author: Bertrand Guiheneuf <Bertrand.Guiheneuf@aful.org> -Date: August 9th 1999 -Last revision date : September 3rd 1999 -Version: 0.2 - -The last version of this document is always available in gnome CVS in -the gnome-mailer module: devel-docs/misc/ref_and_id_proposition.txt - - - -A) Identifying messages within folders --------------------------------------- - -Currently, in Camel there is only one way to retrieve a message from a -mail store: - CamelMimeMessage * - get_message (CamelFolder *folder, gint number) - -where number is an integer representing the message rank within its -parent folder. - -This is a traditional method (JavaMail, MAPI) and it is very useful -because this is often the only way to get a message in from a -classical store (pop3 for example). - -Moreover, various documents ([1], [2]) proposed to generalize the URL -scheme used in Camel ([3]) to access mail stores in order to identify -messages. Such an URL would be, for instance: - -pop3://po.myisp.com:1 - -Meaning: "Access message 1 on Pop3 server po.myisp.com" - - -However, referencing a message with its number within a folder is a -very unreliable method: - -1) Message order in a folder can change during a session: - - The user can move or remove messages from the folder, thus - completely changing message numbers. We could however imagine to - follow message operations in order to keep camel in a coherent - state at each time instant. This could be quite complex but may - be feasible using gtk signal system. - -2) Message order can change between sessions: - - Gnome-mailer was designed from the begining to allow messages to be - stored in classical mailboxes (mbox, maildir, MH, IMAP ...), in - order to allow users to run other MUA on their mailboxes if - necessary. These other MUA can change message order within folders - without any chance for Camel to trace the operations. - -These two scenarii show that it is quite impossible to use reliable -folder caching or message referencing if messages are referenced only -by their position within their parent folder. - - -We thus have to find a general way to identify and retreive a message -within its folder. One thing is sure, however: all folders -implementation won't allow this method. Pop3 stores will always access -messages using their rank on the server. MUA using Camel will thus -have to be prepared to access some stores providing only the old -fashionned message number access method. - -Basically, we have two choices: - -1) Accessing messages using (mailbox) Unique ID (UID) - - A UID is a string identifier associated to a message, which is - guaranteed to be unique within its parent folder and which will not - change between sessions. - -2) Accessing messages using Message ID - - A Message ID is a string identifier associated to a messages which - is guaranteed to be unique in the world, that is, no other message - can have the same Message ID. The message ID is defined in RFC 822, - and is stored as the message header "Message-id" - -Method (1) already exists in IMAP. -It is quite simple to define on local stores (MH, mbox, ....) but it -may not resist to message modification by other MUA. -Methods based on Message-id matching or message content checksum seem -to be the best one. Using an "X-" header is another possibility for -non read-only folders. A combination of these three methods may be the -most reliable solution. -The UID is impossible to implement in a POP3 store provider. - -(2) Can be used with IMAP, but would be very ineficient. -The main issue with this method is its dependancy upon other MUAs and -MTAs. Message-id is set before or during message transport. Moreover, -some rfc822 compliant messages may not even have any Message-id -header. -These are major issues when accessing read-only stores. -The M-ID is also impossible to implement in a POP3 store provider. - - -We may not rely on external MUA and MTA to guarentee the uniqueness of -the identifier . We may loose messages by never being able to read them -if two had the same uid. It would be possible to find workarounds, but -it could make Camel use a bit tricky. - -Given that most users will use IMAP or a database based store as their -main mail store, and given that this stores allow UID very -easily, I suggest that we use method (1). Discussion is still open, -though. - -Here are the public methods I propose to add to CamelFolder: - -gboolean camel_folder_supports_uid (CamelFolder *folder) - returns true if the folder can get messages - by their uid. - -gchar * camel_folder_get_uid_by_number (CamelFolder *folder, gint message_number) - return the uid of message which number in the folder - is %message_number. - -gchar * camel_folder_get_message_uid (CamelFolder *folder, CamelMimeMessage *message) - return the uid of the message within the folder. - -CamelMimeMessage *camel_folder_get_message_by_uid (CamelFolder *folder, gchar *uid) - return the message which uid is %uid - -In addition, the CamelMessage Class will have a new public method - -gchar * camel_mime_message_get_uid (CamelMimeMessage *message) - return the uid associated to the message in its physical parent - folder. - - - -B) Handling message references in (v)folders. ---------------------------------------------- - - -We want the future Gnome mailer to be able to build (virtual) folders -holding references to messages physically located in other -folders. More generally, we would like folders to be able to hold: - -1) messages -2) subfolders -3) references to messages - -(1) and (2) are already implemented in Camel because most mail stores -can hold messages and/or subfolders. - -(3) is a different issue, because no existing mail store can currently -hold, within folders, references to messages in other folders. -It will thus be a specific gnome-mailer extension. - - -One of the main issue is to determine what kind of behaviour we expect -from folders holding references. Here is a possible API. - -( the world (v)folder is used to distinguish between the physical -parent folder and the folder holding a reference to the message, when -a confusion may arise) - -Addition to CamelFolder: - -gboolean camel_folder_can_hold_references (CamelFolder *folder) - return true if the folder can contain references - -void camel_folder_add_reference_by_uid (CamelFolder *folder, gchar *folder_url, gchar *message_uid) - add a reference into a folder. %folder_url is the url of - the folder, %message_uid is the uid of the message within - its physical parent folder. - -void camel_folder_add_reference_by_message (CamelFolder *folder, CamelMessage *message) - add a reference. The place where the reference points - to is found using CamelMessage methods - -void camel_folder_remove_reference_by_uid (CamelFolder *folder, gchar *uid) - remove a message reference form a folder. Reference - is identified using its uid within the folder. - -gboolean camel_folder_uid_is_reference (CamelFolder *folder, gchar *uid) - return true if the message corresponding to the uid is a reference. - -Then all usual operations on the folder act if the message was -actually physically stored in this folder. For example, when the mailer -uses camel_folder_get_message_by_uid onto the (v)folder, the actual -message is retreived from its physical store. - -As you can see, the uid of the message within its physical parent -folder is different than its uid within the (v)folder. This is because -there is no way to guarantee that the uids of two messages in two -different folders would be different. Using references on this two -message in the same vfolder would break uniqueness of the uid in the -(v)folder. - -A couple of other methods could be defined but all the basics are -described here. - -This draft API is far from complete nor perfect, and is described here -only to stimulate discussions before the actual implementation. - - -The question now is to know how we store references. There are basically -two ways: - -1) references are stored using the URL of the physical folder - and the uid of the message within the folder - -2) a list of reference is kept, and in this list, reference are stored -as in (1). Folders would refer to the actual message using index in -the list - - - -The main problem with (1) is that references get lost as soon -as the actual message is moved. There is no way to find in which -folders references to the message exist. - -(2) is a way to solve this issue. When messages are used, Camel looks -in the list to see if the message is refered somewhere, and actualize -the URL and the uid with their new values. - -The problem with (2) is that we need to keep this information in a file -and libraries writing automatically to files are generally a bad idea. - -As in additional remark, it is clear that Camel will only be able to -hold references to messages on stores supporting UIDs. - - -Thanks in advance for your comments and ideas, - - - Bertrand <Bertrand.Guiheneuf@aful.org> - - --- - -[1] : http://www.selequa.com/%7epurp/gnomail/mail2db.html -[2] : http://www.selequa.com/%7epurp/gnomail/dbRecFmt.html -[3] : http://www.gnome.org/mailing-lists/archives/gnome-mailer-list/1999-April/0248.shtml |