Re: RFC mailbox interface

[Kenneth Haley <haleykd yahoo com>]

On 11.18.2001 13:23 M . Thielker wrote:
> Hi,
> 
> On 2001.11.18 20:22 Kenneth Haley wrote:
>> Hi,
>> 
>> You're right that I forgot the void* for internal data, but that is 
>> also where the _Message list would be.  No one should be accessing 
>> it directly.  The copy in routine already supports reference copies, 
>> just store the _Message* in the folders list.  Ref counting may be 
>> needed though.  Changing the _Folder* though may not work, see other 
>> discussion.
> 
> On the contrary, I think people _should_ access the message list, and 
> also the _Folder list of the message. Going though an API to do 
> things that may need to be done in tight loops is inefficient. I'd 
> much rather ahve such simple structures accessible directly. The API 
> description should clearly state that such access is _read only_, if 
> someone does modify the data, on his head be it!

I can see only one time when such a tight loop might occur, that's when 
a folder view is created.  Besides after that balsa should have its own 
list of Message* that could be used for quick access.  Or not, I 
suppose balsa could lose the pointer once it has the header data and 
re-aquire it if it needs to do something else.

> Now, maybe you'd argue, what happens when a message is deleted from a 
> VFolder? Well, it's deleted from thje VFolder. That's all there is to 
> it! It lets me narrow down my search results manually, nothing more. 
> It does not delete the original message!
> To do that, I would have to right click and choose "Delete all 
> instances", which would traverse the folder list, calling 
> delete_message on each.
> Assume I want to delete all messages _not_ matching a complex set of 
> search criteria. I could then do successive searches until I have a 
> VFolder that has all the messages I want to keep. Then I could delete 
> the contents of the original folder and move the VFolder's contents 
> to the original folder. Using true references, the original message 
> would be deleted and the reference useless. That would also make it 
> necessary to have callbacks for UI updates, and so on. No, that's too 
> complicated for my tastes. In my design, the lib will do _exactly_ 
> what it's supposed to do on _exactly_ the message or set of messages 
> given - no side effects, no risks, no confusion. A VFolder is a 
> folder, it can actually store messages, not just references!

OK, I'm convinced that we need an extra Folder list to track vfolders.  
Since I asked about this in another part of this thread I will reply to 
my other message with more details about how I think this could be done.
-- 
K. Haley <halykd@yahoo.com>