Re: RFC mailbox interface
- From: "M . Thielker" <balsa t-data com>
- To: balsa-list gnome org
- Subject: Re: RFC mailbox interface
- Date: Mon, 19 Nov 2001 13:21:22 +0100
On 2001.11.19 10:44 Kenneth Haley wrote:
> Balsa creates the vfolder and populates it with
> vfolder->copyMessage(src). This copies the src pointer into the vfolders
> message list and adds the vfolder to the list in each Message. Just to
> be clear there is only one copy of the Message structure in memory with 2
> or more folders referncing it. Now the fun part.
> If the user deletes the vfolder entry then the message is only removed
> from the vfolder. Balsa has to use its own Folder* here.
> if the user selects delete all on the vfolder or deletes the source
> Message then balsa has to walk the vfolder list in the Message deleting
> it from each one and then delete the source message.
Well, that's in fact contrary to my original thought. I wanted the VFolder
to actually store a copy of the message. When the original message is
deleted, the one in the VFolder should _not_ go away, it should remain and
stay fully usable until the VFolder is closed or the message is explicitly
deleted from it. In my opinion, VFolders should _not_ store references, but
_actual_ messages. The message in a VFolder should, in my opinion, be seen
as a separate entity from the one in the source folder. Of course the same
message structure is referenced in memory, to increase efficiency and
conserve space, but once it's linked into the VFolder, it has a life of
it's own and is no longer related to the source message.
Display-wise, I would like to have an extra field to indicate if the
message is in more than one folder. So if I copied a message from my inbox
to my "done" folder, and opened it from there, I would see "Also in
folder(s): Inbox" somewhere
So, if a message in a VFolder is opened/looked at, the Also in folder(s)
line would show the source folder(s). In fact, a message can be in more
than 2 folders, I could theoretically copy it to every folder on my system,
remote or local, and it would still be just _one_ message structure in
memory. Using the message GUIDs I proposed, the message would be detected
as being a duplicate of an already loaded message and not retrieved from
storage again, but linked from the existing message structure when a folder
containing a message that has already been loaded from another folder is
If it's done like that, local shadows for IMAP are a snap!
Of course this processing model assumes that no messages stored in folders
are edited by other applications. It's normally impossible, and
undesirable, to be able to edit a received message, so I should be on the
safe side with that assumption.
Add to this that all local folders should be opened/scanned before any
remote folder and one would have a very basic IMAP shadow by just copying
all messages from the IMAP to a local folder. Open that local folder, then
the IMAP one and only those messages that have been added to the IMAP
folder since it was last accessed will be transferred across the net,
because all others are already loaded. Now, hook it up so that every
message that needs to be loaded from the IMAP server is automagically
copied into that local folder, and you have a local shadow, at no extra
cost. Now, give that folder a special prefix in it's name, like
#shadow:<imap server>:<imap path> and set it up so that all folders
beginning with #shadow: are not displayed and it's done - local IMAP
The next step would be to link the IMAP folder's definition to the shadow
folder in such a way that, when an operation is performed on the IMAP
folder it's actually done on the shadow folder. Another thread could do the
syncing between shadow and IMAP, copying all messages that were
copied/moved there into storage on the IMAP server.
The last step would be to have a log of message actions on such a shadow
folder, so that, when modifications have been made while the IMAP server
was unreachable, it can be played back on the next successful connect.
Thinking in that direction, it makes a lot of sense to do it that way,
making VFolder messages _real_ entities in their own right.
If a MUA wants to present them as references rather than real copies, it's
free to walk the list as you said and delete the references when the last
copy of the source message is deleted.
This gives lots of flexibility for the writers of MUA's, as a matter of
fact it would not be much work to make the reference/copy choice a prefs
Doing the lib in such a way would leave the choice to the user instead of
locking the user into a set pattern that would require hacks to work
around, should something else be desired.
] [Thread Prev