libfetchmail (was Re: Camel)

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.


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:
> -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:
> vel-docs
> mel
> So, given that, where do we start, peter? :)

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