Re: new mailbox stuff

[Nic Ferrier]

Sam Roberts <address@hidden> writes:

> Bon soir, Alain et tout le monde aussi. 
>  
> My 2 cents: 
>  
> I like some of the work done in mailbox2, but I think it should be 
> applied to mailbox. I think the needs of the (fairly diverse) set 
> of programs built on the API will drive it in a good direction. 
>  
> Also, the API doesn't have to be stable... we'd like the utilities 
> to continue to become more and more stable, but we can rearrange 
> the internals as much as we need. 
>  
> Besides tweaks in the stream, debug, error, etc. internal interfaces, 
> which aren't particularly disruptive and are happening now, mailbox2 
> has a only a few big changes that I know about (haven't read to 
> closely): 
>  
> - a protocol layer (pop3, smtp, ...) and an abstract layer. I 
>   really think this is the Right Way. Make an api that does exactly 
>   what pop can do, imap can do, ..., then wrap them to give a uniform 
>   interface. 
>  
> - messages take resources in mailboxes that are never freed, so we 
>   need an API to free/release them. We need this because messages to 
>   mailboxes are many-to-one. I still don't think we need to free/reference 
>   count the pieces gotten from a message, they are one-to-one, 
>   and their lifetime is clearly that of the message they came from. 
>  
> - I think you have the idea of making the interfaces more "pure" interface 
>   rather than being more like C++ classes with virtual functions, 
>   and derived classes kindof overriding and/or augmenting the bases. 
>   I think this could be nice, certainly sounds cleaner, worth doing, 
>   etc., but isn't bothering me in my day-to-day use of mailutils. 
>  
> I'm a big fan of evolving the code, really quickly, even. Migrating 
> slowly over to mailbox2, maintaining two code bases, etc, seems 
> time consuming, and I don't have that time, myself. If we had 1000s 
> of customers, and we would lose them if the API changed, that would 
> be different, but we don't. So, lets adopt hack-in-place development. 
>  

Your ideas sound good to me...


> Also, somebody might want to mention to Nic that we don't have 
> maildir support... but he can fix that! Theres some code in libmailbox 
> it looks like. 

I would be happy to write maildir support, but I'd like to know that
I'm not going to have to re-write in 6 months time when you guys do
mailbox2.



Nic