libfetchmail (was Re: Camel)

[Anthony Joseph Seward <seward hplyot obspm fr>]

Is there any reason for not making a libfetchmail?  It seems to me that most
of the functionality for a transport library is already in the fetchmail
program.  All that remains is to seperate what would be useful for a library
from the fetchmail interface and the add any functionality that it currently
lacks.  Is there some problem with this?

Just a suggestion.

Tony

On Mon, 14 Jun 1999, David Fallon wrote:

> >From my fairly preliminary investigation, camel is waay far away from being
> alpha, much less useful for balsa. That, and I disagree with some design
> decisions they're making... The point is to try and build this
> "all-encompassing", and very generic, message handler... I think it would be
> a *lot* more useful to skip the abstraction stuff, and just build a series
> of libraries to provide access to the various protocols, (libpop3, libimap4,
> etc.). Not only will balsa benefit, but then anyone else out there who wants
> to use the pop3 protocol (say, all those silly people that write mail
> checkers for the toolbar), will have the library to use also.
> 
> Check out some of the proposed camel structure:
> http://cvs.gnome.org/lxr/source/gnome-mailer/devel-docs/query/virtual-folder
> -in-depth.txt
> 
> For the most part, I think this is waay too abstract to be useful, but there
> are some good points in here (esp. the message notation concept near the
> end.) Something to keep in mind...
> 
> Check out the rest of camel in:
> http://cvs.gnome.org/bonsai/rview.cgi?dir=gnome-mailer&cvsroot=/cvs/gnome
> http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=gnome-mailer/de
> vel-docs
> http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=gnome-mailer/ca
> mel
> 
> So, given that, where do we start, peter? :)
> 
>