Re: RFC mailbox interface

[Kenneth Haley <haleykd yahoo com>]

On 11.18.2001 13:07 Kenneth Haley wrote:
> On 11.17.2001 03:02 M . Thielker wrote:
>> Hi Pawel,
>> 
>> On 2001.11.17 10:55 Pawel Salek wrote:
>>> 
>>> On 2001.11.17 06:58 Kenneth Haley wrote:
>>>> After following this thread I came up with the following interface.
>>>> 
>>>> typedef struct _Message {
>>>> 	struct _Folder *Folder;
>>>> 	Flags flags;
>>>> 	//perhaps return a string instead?
>>>> 	glist (*getHeaders)(const char[] hdrs);
>>>> 	glist (*getAllHeaders)();
>>>> 	char* (*getBody)();
>>>> 	char* (*getAll)();
>>>> };
>>> 
>>> Are these methods not specific to the mailbox that owns the Message?
>>> I imagine that following scheme would be a better solution:
>>> glist
>>> lib_message_getHeaders(Message* msg)
>>> { msg->folder->getHeaders(msg->folder, msg); }
>> 
>> Yes, right. That was in my original proposal, as a matter of fact, 
>> except that I had separated the function pointers from the mailbox 
>> struct initially, putting them into a mailboxTYPE struct that was 
>> referenced by the mailbox struct. That way, they only need to be set 
>> up once, not copied each time.
>> There's no point in hving to drag along these pointers with each 
>> message.
>> 
>> Melanie
> 
> You're right, it would be  better to move those functions into the 
> Folder.  As for using a folder-type* instead of having the functions 
> directly in the Folder I don't see that it makes a big difference.
> 
> Perhaps open and close should be changed to lock and unlock.  It 
> would make more sense at this level.  After all you would not want to 
> open an mbox file without locking it so....
> 
> I just thought of a problem with vfolders.  Remember that there is 
> only one Message struct per source message.  What happens when a user 
> deletes
> a) the vfolder message
> b) the source message

Looks like I'm replying to myself again.  This is based on some 
comments from Melanie in another part of the thread.  The only change 
to the API is to add a Folder list to the Message for holding the 
vfolders that contain the message.  It also requires that balsa keeps 
and uses its own copy of the Folder* at least for vfolders.  This is 
how I currently see the life of a vfolder:

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.

-- 
K. Haley <halykd@yahoo.com>