Re: RFC mailbox interface

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

On 2001.11.22 10:39 Kenneth Haley wrote:
> you do realize that this would require changing your preferences to tell 
> the IMAP mailbox that you don't want to connect to the remote server 
> right?

Yes, of course. Instead of having a single check box "Check for new mail", 
I would have "Always check for new mail", "Ask always", "Check when not 
using a dialup" and "Don't check".

> This would be easier to do by craeting a new mailbox type whose check 
> routine updates the IMAP server to/from the shadow while all other 
> routines operate on the shadow.  Even this would require 
> enabling/disabling the check so that while your using the dialup it 
> doesn't connect to the server.
> 
Right, that's what I did have in mind.

> You know this could probably be done with one vfolder type and a balsa 
> pref.
> If balsa is set for reference vfolders then balsa would act like the 
> first case.  It would delete the Message from each of the vfolders then 
> from the source.
> If balsa was set to copy on delete then it would be more like the second 
> case.  First balsa would delete then Message from all of the vfolders.  
> Then it would retreive the message data from the source and use 
> addMessage to put it into one of the vfolders.  Next it would get the 
> Message* from that vfolder and use copyMessage to put it into the 
> others.  Finaly balsa would delete the source message.  The vfolders know 
> to treat the message differently because Message->folder=NULL.  This 
> means that balsa must use its own copy of the Folder*.

Far too complicated. Imagine this:

The message is already displayed in an index. Therefore, a _Message 
structure is in memory already. The headers have been loaded ans parsed, 
but there is no associated message data. The _Message is a memeber of one 
or more VFolders, in addition to the main folder it's in. If you want to 
copy it to memory before deleting it from disk, all you need to do is 
delete it from it's source mailbox. At that point the lib will see that the 
message's last on-disk copy is about to be deleted , but the message is 
references by other folders. So it would load the message, then delete it 
from disk.
This would be all that has to be done for copy on delete.

If you want to treat the VFolders as views, all you have to do is walt the 
folder list of the _Message, typically it's very short. Delete the message 
from any folder that references it and has _no_ associated backing store. 
Finally, delete it from the source folder. Also very simple.

In either case, the lib doesn't know, so you can even mix VFolder types 
(View type and persistent type).

A piece of code may illustrate this:

void delete_from_views(_Message *message)
{
	GList *current;

	current=_Message->folder_list;

	if(current)
	{
		do
		{
			if((_Folder*)(current->data)->type == 
FOLDER_VIRTUAL)
				delete_from_folder((_Folder 
*)(current->data), message);
		} while ((current=g_list_next(current)) != NULL);
	}
}

void delete_message(_Folder *folder, _Message *message)
{
	GList *current;

	if(config.vfolders_are_views)
		delete_from_views(message);

	delete_from_folder(folder, message);
}

The delete_from_views function is the _only_ extra code needed in the app 
to implememnt this behavior.

Melanie