Re: RFC mailbox interface

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

On 2001.11.22 01:33 Carlos Morgado wrote:
> err, where do you get pop3 from if your disconnected ? :) dial and 
> diferent
> server ? or you're fetching from the same server ? that strikes me as 
> daft.
> 
I connect once per day from the hotel room, download all pop3 mail, then 
disconnect again.

> Evolution does this fairly well as far as i know. at least they were quite
> proud of their disconnected mode :)
> 
Well, Evolution doesn't do other things well...

>> 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.
>> 
> how so ?
> 
Because every email received would be placed in the shadow at the time it's 
uploaded to the server, so they'd stay in sync.

>> 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.
>> 
> pray tell, how is MAPI so revolutionary ?
> 
MAPI isn't. Functionality like MAPI just simply doesn't exist on the Linux 
desktop yet. The revolutionary thing would be that functionality. Accessing 
Exchange server folders through MAPI is just an added bonus that could get 
more people to switch to Linux.

>> 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
> 
> how do you intend to do this in a way that doesn't blow dead bears ?
> 
By, as I outlined before, exposing the lists of message to folder and 
folder to messages to the programmer as part of the API. That will let the 
email client's programmer find the most efficient way to deal with it.

>> 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.
>> 
> what do you mean by kind of messages ?
> 
Permanent or transient, search result or real message, the lib isn't 
supposed to know.

> huau, you just described evolution. you forgot to mention the bonobo
> bits though, and that turns into an abomination like openssl user
> interaction
> 
No. To me, Bonobo is like M$ OLE - something to avoid if possible. I'm 
thinking of a far more simple interface, one designed to do just one thing 
and do it well, not one to try and do everything - by halves.

> you don't even need that. your magic lib gives you an index and you
> play with that. virtual or real is only a mather of backing store.
> 
The app needs to know if it's virtual or real because it needs to treat 
virtual ones differently, should it choose to treat a folder as a database 
view. In that case it needs to walk the folder list and delete the message 
from any folder that's virtual _before_ deleting it from a folder that has 
a backing store. Failing to do so would, in this concept, cause te message 
to be loaded into memory from the backing store when the last on-disk copy 
is deleted.

> I sugest you look at Camel. it does all this (and then more prolly)
> i doubt it fits anyone's definition of simple. i'm sure everyone
> will be very thankfull if you can simplify it.
> 
Well, isn't the Camel's back broken? Anyway, that means Bonobo again, long 
app startup times, heaps of disk accesses and screwy interfaces, doesn't it?

Melanie