Re: RFC mailbox interface

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

On 2001.11.22 22:20 Kenneth Haley wrote:
> Is this what your thinking?
> 
> struct _Message {
> 	struct _Folder *owner;
> 	glist views;  //a pointer perhaps?
> 	char[] //misc. headers ie. Date ...
> 	void *data;	//opaque mailbox data
> 	struct _MsgData *msgdata;	//used by vfolders
> }
> where _MsgData is defined in an internal header and contains the message 
> data.  We don't want balsa or anyone else trying to use the data in there.
> _Folder->deleteMessage fills in msgdata if it is the owner and sets 
> owner=NULL.

Just drop the owner. The entire idea behind my concept is to have no such 
thing as an owner:

struct _Foldertype
{
	int type_id;
	int (*delete_message)(struct _Message *);
	int (*get_message)(struct _Message *);
	.
	.
	.
	int (*has_backing_store)(void);
};

struct _Folder
{
	struct _Foldertype *type;
	struct _Server *server;
	GList *messages;
	char *display_name;
};

struct _Message
{
	char hash[64];
	glist *folders;
	.
	.
	.
};

There really is _no_ definite owner of a message. If a message is deleted, 
it looks like this (in the lib):

int _type1_delete_message(struct _Folder *folder, struct _Message *message)
{
	glist *scan;
	int load=1;
	int folders=0;

	scan=message->folders;
	if(scan)
	{
		do
		{
			if(scan->data == folder)
				continue;
			folders++;
			if(*((_Folder 
*)(scan->data)->type->has_backing_store)())
			{
				load=0;
				break;
			}
		} while((scan=g_list_next(scan)) != NULL);
	}
	if(load && folders)
		_type1_load_message(message);
	 
	/* Delete from glist here */

	if(!folders)
	{
		/* Free message in memory here */
	}
	/* and delete it from disk */
	_type1_delete_from_disk(message);

	return(0);
}

This is what it would look like for a folder that has a backing store. On 
one without a backing store, it would simply remove the message from the 
list and free it's memory if there are no more references (i.e. 
message->folders == NULL)
That "folders" variable is to avoid an unnecessary load of a message not 
completely in memory when the last reference is a folder with backing store 
and the message is being deleted.
Note that there is no need to load the message at this time if another 
folder with a backing store still has a copy, "load" tracks that. To avoid 
loading a message when it's deleted, all the client needs to do is remove 
it from all virtual folders first, using the has_backing_store API call to 
find out which are virtual.
Also note that the load_message wrapper (the main load_message function of 
the lib) can use the information found in the _Foldertype structure to 
assess the proximity of a server and prefer the fastest one to load the 
message from, e.g. local maildir/mh first, local mbox second, IMAP on the 
same subnet third. other IMAP fourth.....

Melanie