Re: RFC mailbox interface

On 11.22.2001 03:23 M . Thielker wrote:
> 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".

The dialup option would require either telling balsa your on dialup or 
having it check for itself (not good).  The other options are OK and 
would probably be enough.

>> 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.

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 

> 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.

The views list will be managed by the vfolders.  When you put a message 
into a vfolder it adds itself to the views list.  When you delete a 
message from the list it checks to see if it was the last folder to use 
that message ( views empty && owner==NULL) if so it must free the 
K. Haley <>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]