Stuart Anderson <[EMAIL PROTECTED]> writes: > On 30 Nov 1999, Jakob 'sparky' Kaivo wrote: > > > Stuart Anderson <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]:/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 - [EMAIL PROTECTED] - http://jakob.kaivo.net/
