Re: GNOME plans (--> mail clients)

[rsinha glue umd edu]

why must the mailer have fetchmail and procmail built in?

simple calls to Unix philosophy (small, self-contained apps used
together (or by larger ones) to do various things...) aside:

simplicity would suggest just binding to them, having a configuration
front-end, and in the case of fetchmail, have an option to have a dialog
pop up that would give the realtime output (tail -f ~/.fetchmail.log)

the argument that embedding these apps complicates the install
process falls flat when one looks at GNOME's installation package (a
marathon compilation session involving 20+ packages OR a bunch of rpms (to
which adding fetchmail and procmail would not hurt anything)

these tools are much more powerful than anything GNOME developers should
be spending their time duplicating, esp with all the work left to do...
the difficulty of configuration can be easily surmounted with the config
front-end

and new features coming from outside gnome will transparently propagate
in, while new features GNOME developers want to implement will (by being
added to the "industry" standard apps) be enjoyed by all...

at most have some plugin architechture, so that the initial releases can
simply have plugins that bind to fetchmail and procmail, while later the
truely zealous NIH (Not-Invented-Here) types can make their own plugin,
that is self-contained...

this debate ran on balsa-l for a while, and while I left it in April, at
that time the decision was to stick with procmail and fetchmail... at that
point some weirdness happened with leadership.. and the rest is history...

	-RS
                             Rahul Sinha
     rsinha@glue.umd.edu    ICQ# 9738191      AOL IM: vox deus
             Freshman               Developer, Global Land Cover Facility
   Computer Science / Government    Treasurer, UM Linux Users' Group
University Of Maryland College Park Vice President, UM Debate Team