Re: RFC mailbox interface

[Carlos Morgado <chbm chbm nu>]

Em Qui, 22 Nov 2001 09:57:25 M . Thielker escreveu:
> 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.
> 

why don't you just connect via imap ?

> 
>>> 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.
> 
how do you know it's the same message if they came from diferent servers ?


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

You still didn't explain what's so great about MAPI ...
> 
>>> 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.
> 

aren't this lists O(n^2) ?
> 
>> 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.
> 

in this case it would allow the backend to provide a config object that the
UI would Control and avoid the kludginess of an abstract definition of
what the user needs to input and how the dialog looks like.
>> 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

that is, just removing it from the index right ?

> 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.
> 
hum. cache coherency.
what if the message disapears from under our feet ? how do you garantee all 
views learn about it ?

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

humm, no. camel handles all mail stuff including imap quircks and
disconnected mode. fun reading if you like twisted sick stuff

-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A 
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
"If you wish to make an apple pie from scratch, you must first invent the 
universe." -- Carl Sagan