Re: RFC mailbox interface

["M . Thielker" <balsa t-data com>]

Hi,

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 
accessed.
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 
shadowing.
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 
option.
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.

Melanie