Re: RFC mailbox interface

[Carlos Morgado <chbm chbm nu>]

Em Qua, 21 Nov 2001 20:33:45 M . Thielker escreveu:
> Hi,
> 


> Use the notebook while disconnected, receiving pop3 email and filing it 
> into offline IMAP shadows.

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.

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

Evolution does this fairly well as far as i know. at least they were quite
proud of their disconnected mode :)

>> 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.
> 
how so ?

>> 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.
> 
pray tell, how is MAPI so revolutionary ?

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

how do you intend to do this in a way that doesn't blow dead bears ?

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

This is totally broken. It means that at any given point in time the user
doesn't actually know where the message actually is. "vfolders are memory
based" isn't correct either. somewhere in another thread persistant
vfolder/views were talked about

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

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

huau, you just described evolution. you forgot to mention the bonobo
bits though, and that turns into an abomination like openssl user
interaction

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

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

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.

-- 
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
RSA in 3 lines of PERL :
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=cho 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc;s/\W//g;$_=pack('H*',/((..)*)$/)