Re: RFC mailbox interface

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

Hi,

On 2001.11.20 07:52 Kenneth Haley wrote:
> 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
If any of these is untrue, there would be no point in having the shadow. In 
my opinion, one of the most valuable uses for such a shadow is on notebook 
computers. It allows me to work with my email as if I were connected, while 
in fact I'm not.
Leter on, when I connect, all will be as if I had been connected all along. 
So, I would do this:
Keep _all_ mailboxes on an IMAP server.
Keep a shadow on the notebook. No shadow on the regular computer, because 
it's on a local network with the IMAP server.
Close Balsa on the main computer.
Connect to the IMAP server before I leave the office, using my notebook. 
This will update the shadow on the notebook to reflect all I've done in the 
office.
Use the notebook while disconnected, receiving pop3 email and filing it 
into offline IMAP shadows.
Connect to the IMAP server when I'm back in the office, it will upload all 
mail added since I left when the folders are synchronized.
Shut down the notebook and put it away until my next trip, open Balsa on my 
main machine.

 From an email point of view, it's like having your office PC with you at 
all times. That is what I would like to have. M$, a company that pays 
usability researchers big money, provides this functionality, though it's 
somewhat broken where IMAP is concerned. It works with MAPI, which is 
probably all they want, anyway. I would like to have that for IMAP, maybe 
add MAPI support later on.

Not having that functionality in their email clients is people's one most 
often stated reason for not switching desktop machines to Linux.

> 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

If the IMAP server is the server that's used to receive mail, that may be 
so. If, on the other hand, email is received by pop3, the by far more 
common way, and only filed into IMAP, for shared availability, the shadow 
would automatically have the proper content.

> 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.
> 
Of course, but again defeats the main purpose. If Balsa would allow 
handling IMAP folders the way M$ handles MAPI, that would be a major 
breakthrough in unix email clients.

>  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?
> 
Well, all I'm really saying is that the _library_ should _not_ make that 
assumption, but give the option to choose to the _client_! If the email 
client decides to treat a VFolder as a view, all it needs to do is to 
delete the message from all VFolders first, then from the real folder. That 
would really be one single case where extra programming would be needed for 
VFolders in the email client. A small price to pay for total flexibility! 
If the library doesn't allow creating a folder without associated backing 
store, all it does by that is limit it's use. The email client is far 
better equipped to decide whether a VFolder is used as a shadow, a 
temporary, memory based message store, a view of search results or a real 
folder view. This assumption is not for the library to make.

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

If the internal data structures are done well, the delete function would 
easily be able to determine when that copy is needed to be done. Since 
VFolders are memory based, it only means copying the entire message as a 
string into allocated storage attached to the message structure that 
already exists in memory anyway.

So I think that the lib should know what backing store, if any, is 
associated with a folder, and if there is a local shadow for a remote 
folder.
It should not know what kind of messages will be stored there.

The email client knows about what kind of data is in a folder and what use 
the folder has in the email client. It should not know, or care, about the 
backing store, unless the user is working with prefs to actually define 
mailboxes. For creating mailbox prefs, I would have the lib give a list of 
"Text, Type, Limit, Datatype" sets that the app can use to build a dialog 
with, so the app has no real own knowledge of the type of data required to 
create an individaul mailbox of a certain kind. I would give the lib some 
function to save such a mailbox definition to a config file. The process of 
creating a new mailbox would then be thus:

Get the list of mailbox types supported from the lib.
Make a list and let the user select one.
Get the list if data definitions from the lib.
Make a dialog from them, let the user fill it and return the user's input 
to the lib.
Re-prompt the user if the imput was not validated by the lib.
Receive a folder handle from the lib.
Call the lib to save the prefs for that folder to a config file.

Now the app has a folder handle, but doesn't even know what type of folder 
it is, and that's the way I think it should be.
When I do a message search, the search parameters are given to the lib and 
a folder handle is returned. All I can find out about that handle is 
whether it's virtual or real.

All other managemant tasks would be up to the app, not the lib.

That keeps the library simple and the API clean by allowing great 
flexibility in using it. That is what I would like to see.

Melanie