Re: RFC mailbox interface

[Kenneth Haley <haleykd yahoo com>]

On 11.19.2001 10:07 M . Thielker wrote:
> 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.
snip
> 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.

You're assuming that the shadow is always on and that it keeps a 
complete mirror of the IMAP server, both of which are faulty.  A user 
may not want all messages downloaded automatically, thus the shadow 
would contain only those messages that the user has read.  A user may 
not want a particular server shadowed, at least not on all systems.  A 
user may have limited space so the local shadow becomes a size limited 
cache possibly automatically downloading NEW messages.  Of course this 
would require extending the API to allow these settings.

>> 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.
  As I understand it the only current use for vfolders would be to hold 
search results, if I'm wrong say so.  In this case if you delete the 
source message your saying that you have no need for it so why shuld a 
copy of it be kept around?

It looks like there are three ways the vfolders could be done.
1) The vfolder works by refernce.  This requires an extra feild in the 
Message struct, either a glist or a counter.  And balsa stores its own 
copy of the Folder* for each folder.  sudo code:
delete issued in folder on msg
if folder== msc->folder then
	if msg has other views
		tell other views to delete message
folder->deleteMessage(msg)

2) The vfolder has its own copy of all message data.  In this case the 
vfolder server maintains a global list or hash of all messages stored 
in all vfolders.  This acts like the physical storage of the other 
mailboxes.  When a message is copied into a vfolder its msgID is 
compared to the msgID's of all the other messages in the global list.  
If it's found then that copy is used else the complete message is added 
to the list.  Any sort of refernce counting would be internal to the 
vfolder system with no special action required by balsa.  The problem 
is that a complete copy of each message must be transfered into the 
vfolder system.

3) Melanie seems to be suggesting a combination of the two where the 
message data is only copied in if the source message is deleted.  That 
looks like a rather complex solution.
-- 
K. Haley <halykd@yahoo.com>