libmail? (was: Re: /usr/sbin/sendmail specification proposal, draft 4)
Stuart Anderson <anderson@metrolink.com> writes:
> On 30 Nov 1999, Jakob 'sparky' Kaivo wrote:
>
> > Stuart Anderson <anderson@metrolink.com> writes:
> >
> > > This is what I have though was needed for a long time. Doesn't c-client
> > > provide most of this functionallity?
>
> As a followup to myself, a URL for c-client is http://www.washington.edu/imap.
I have put what documentation there is (in texi, info, and html) for
mailutils at http://www.ndn.net/software/mailutils/. The developmnet
tree is on anonymous cvs at
:pserver:anoncvs@anoncvs.gnu.org:/gd/gnu/anoncvsroot, module name is
mailutils. Another fellow (Alain Magloire) is the maintainer, I just
sent him an e-mail asking about possible release estimates, and will
forward appropriate information.
> > Yes, but c-client is horribly slow, leaves mailboxes with annoying "DO
> > NOT DELETE THIS MESSAGE -- FOLDER INTERNAL DATA" messages, and is
> > under the circumspect UW license...
>
> I won't argue that it is perfect and should be adopted, but I do think that
> conceptually it is very close.
We have been playing with a few ideas to overcome this, since it is
needed to store IMAP state information. As you said, conceptually it
is very close, but quite annoying if you access a mailbox with a
program that uses c-client and then with something that doesn't.
> > But, there is hope. I have been working (with a couple of others) on
> > the forthcoming GNU mailutils package, which includes, among other
> > things, a library (may become libraries) that provide better than
> > c-client funcionality under LGPL.
>
> This would be wonderful, especially if the library is a nice clean layer that
> isn't tied to closely to the rest ofthe apps in the package.
Yes, the library is made to be useful apart from the other
applications (rather, the applications are tied to the library). One
of the developers is working on yet another
elm/pine/mutt/whatever-like client using the library as a sort of test case.
> > case the API is still under development and can still be adaptable to
> > emerging standards such as this. Comments are, of course, welcome.
>
> Please document what you have, and propose it so we can discuss it and provide
> feedback.
Note the URL above, and I am coordinating with Alain to get some
better documentation soon. I'll make a more formal proposal (if there
is still interest) when the docs are a bit more complete.
--
Jakob 'sparky' Kaivo - jkaivo@ndn.net - http://jakob.kaivo.net/
Reply to: