bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new mailbox stuff


From: Sam Roberts
Subject: Re: new mailbox stuff
Date: Tue, 19 Feb 2002 22:44:53 -0500
User-agent: Mutt/1.3.16i

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.

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.

Ciao,
Sam


Quoting Alain Magloire <address@hidden>, who wrote:
> > 
> > Is the new mailbox API done yet? 
> > 
> > I promised myself I would move to mailutils when you had 
> > finished the new mailbox API (I might have to fix your 
> > maildir stuff first, right?)
> > 
> > I wish you guys would set up a mailing list so other 
> > people could follow your development.
> > 
> > 
> 
> Bonjour Nic
> 
>   a) Developement is going good. See <address@hidden> archives
> The guys on the list are keeping very busy.  Unfortunately I can
> not take part of it for now, working 7 days a week on a new Project
> the little time left is for .. sleeping 8-).
> 
>   b) I'm not sure what you meant by the mailing list is not setup
> because it is.  Unless you meant that it is not visible from
> savannah?  Do not know if Jeff can help with this.
> 
>   c) For the new API,(mailutils2), the other guys are pushing so
> hard on the old (mailutils) that it has become hard to merge the two.
> Maybe the best approach is to let the first release go and from the
> feedbacks do a proper design on a clean sheet.
> 
>       Sergey/Sam/Jeff and all comments ?
> 
> That's all the time I have, EOT.
> 
> 

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]