Re: RFC mailbox interface

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

Hi,

On 2001.11.19 13:28 Pawel Salek wrote:
> This implementation would require downloading all the messages in the 
> VFolder (so they are available even when removed from original mailboxes) 
> which is hardly one would like to do.
> 
No, that will not be necessary. When a folder is opened, sufficient 
information is retrieved from the backing store to display an index. That 
index-relevant data is associated with the _Message. Inserting it into a 
VFolder does not mean downloading the entire message, therefore, but only 
re-associating the headers.
Well, if, and only if, the last copy of a message in _any_ backing store 
were to be deleted from that folder while contained in a VFolder, the 
entire message would need to be downloaded. That could be made an option. 
VFolders are so much more usable if it's possible to actually store 
messages in them, not just references. Also, all the clutter needed in 
other code, is this a message or a ref, treat it thus or thus, lots of 
places where code would need to be written to take differences in behavior 
between messages and refs into account. By having only one type, this would 
all be cleaner.
Also, I'm simply assuming that a local shadow for IMAP is in the not too 
distant future, so a download just for the sake of having a message stored 
in a VFolder would not be needed, it's already stored in the local shadow. 
Easy enough to load that into memory before deleting it on disk.

> I think is is better to keep it more like views in database: when data is 
> removed from table, it is removed from the view as well. One can always 
> make views persistent, but only on request.

I abhor that concept, to tell the truth. I don't like things I have set 
aside to up and change on me while I'm not looking. From a programmers 
point of view, things are much more stremlined if there is exactly _one_ 
type of folder and exactly _one_ type of message present in the interface.

Melanie