[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new mailbox stuff
From: |
Nic Ferrier |
Subject: |
Re: new mailbox stuff |
Date: |
21 Feb 2002 10:47:44 +0000 |
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