Re: Configuration

[Gleef <dzol virtual-yellow com>]

First off, the email I'm replying to demonstrates a bug, Balsa
really shouldn't  be sending mail with 974 characters on a line, or at
least it should require the sender to consciously choose whether or not to
violate convention.

On Wed, 3 Mar 1999, Scott Tyson wrote:
[edited for readability]
> On Wed, 03 Mar 1999 04:49:46 Jules Bean wrote:
> > On Wed, 3 Mar 1999, Walt Armour wrote:
> > > Hmmm...  Warning: non-procmail user here.  :)
> > > 
> > > Anyway, the primary thing I was trying to avoid was requiring
> > > the user to configure other software packages in order to get
> > > their mail.  When I say 'transparent' I mean that Joe User
> > > should not have to worry about configuring/maintaining it.  If
> > > we can achieve this with the current procmail then perhaps we
> > > should use it.
> > 
> > Certainly, that kind of transparency is desirable.
> > 
> > I wonder if perhaps this is really the domain of a gnome-mail
> > configurator, which understands the chain
> > 
> > mail-transport-agent
> > mail-delivery-agent
> > mail-user-agent
> > 
> > (Ie. sendmail-procmail-balsa, or exim-procmail-balsa)
> > 
> > and knows how to configure a few alternatives for each level.
> > 
> > OTOH, that's probably a fairly large project.  It may be the technically
> > neatest approach, though.
>
> I think people are forgetting some of the goals associated with the
> GNOME Environment.  If Linux is to make inroads into the desktop
> market as a viable alternative to windows it must be just as easy to
> use for the layman.

First off, helping Linux make inroads into the desktop market was
never one of the goals of GNOME.  To quote the GNOME Manifesto:
"Gnome is an Open Source desktop environment built from components
that meet the Open Source guidelines in full."  Basically, we want to
write an excellent desktop, that is both powerful and easy to use.
Leave worrying about market share to the companies.

Secondly, yes GNOME should be easy to use for the layman.  However,
keep in mind that a computer is a complex thing, getting more complex
all the time.  What this means is that _configuring_ a system will
never be a trivial task, not in Linux, not in Windows, not in MacOS.
I would call email filtering, regardless of where it's done, a
configuration issue.

Most laypeople deal with this by buying preconfigured machines for
their home, and having the IS department configure their desktop
machines at work.  This is why the iMac has been selling so well, not
because it's easy to configure, but because 99.9% of the configuration
is already done for you.

We should definately try to make configuration issues more accessible
to laypeople, and provide tools to make things as easy as possible,
but it will never be truly _easy_.


> Think of it this way.  I would not want my father messing with
> procmail/fetchmail for email reading/filtering.  It might be a
> powerfull and flexible setup but it is far to cryptic and different
> from what he is used to.  Linux mailers have to drop the old school
> unix mailer persona and embrace what programs like Eudora and
> Calypso (my persnal fav for windows mailer) and Outlook Express
> offer.

We also shouldn't reinvent the wheel, like most Windows mailer
programs do.  Rather than having Balsa do the mail filtering itself,
and rather than forcing users to figure out the difference between
":0" and ":0c", why not have Balsa give an easy to use and understand
GUI tool to edit and create .procmailrc files.  It would be easier to
write than a full-featured filtering system, and more useful in general.


> They are simple to use and offer all the tools to handle
> multiple accounts, filtering, etc.  I personally HATE having mess
> with procnmail and fetchmail (I use fetchpop).  Coming from NT and
> using Calypso and going to this setup is backwards to me.  It took
> me almost a week just to setup fetchpop and proccmail and I only
> have 3 different folders my mail is dumbed into.

Yes, simple configurations are easier to do in a typical Windows
mailer than the current state of procmail (although I found fetchmail
configuration trivial, I don't know what problem you had with it).
However, I for example, have five different email accounts that need to
deal with seven machines running three different operating systems; four
of the machines are headless.  I live on procmail, no GUI mail
filtering tool even comes close to what I need. 


> I could have done the same thing in Calypso in about 5 minutes.  My
> new found knowlegde of fetchpop and procmail may be great for
> prosperaty but the bottom line is I spent over 15 hours on a task
> that should have taken 5 minutes.  My mailer should get my mail for
> me and filter it for me. 

Yes, and I agree that Balsa should make it easier for someone to do
this.  I just want a solution that won't sacrifice existing
functionality.


> This is industgry standard desktop email software feature set.

I beg to differ.  Most mail systems I have used, even with Windows,
have had mail server software handling transport and filtering, and a
separate client program for viewing.  For example, most of Microsoft
Outlook's "filtering" features are actually a front end for
configuring Exchange Server's filtering settings.  That has been and
continues to be the industry standard in my book.

 
> I understand that this is re-inventing the wheel and is going
> against how things have been done in the *nix world but linux apps
> cannot ingore what the avereage PC user's expectations are.  They
> need to offer features that will satisfy those needs.

Sure we can.  In this case I don't think we should, but we are not
beholden to Windows for our feature set.


> This is why many of GNOME's tools look like their windows
> coutnerparts.  Windows has established a feature set that cannot be
> ignored.  GNOME differes in its execution of these and the
> underlying technologies but it still needs to address them.

GNOME should address the needs of users because we want to be friendly
to the users.  We cannot take the attitude where we must implement
something because Windows does.


> I think there are many in the Linux community that shun anything
> associated with Windows jsut because it comes from Windows without
> weighing it on its own merits

There are those who feel that way, but most of them aren't in GNOME.
Most of us feel that we should implement the best stuff out there,
regardless of where the idea came from originally.


> or considering if its a standard or not.

Linux in general and GNOME in particular pays a lot of attention to
standards.  What you don't seem to realize is how little of Windows is
standard.  Not only don't they pay attention to the industry standards
in their designs, but they also tend to not keep their programs
compatible with each other.  For example, Windows 95 has shipped with
three different mail clients (two versions of Exchange, plus Outlook),
none of which were compatible with each other in look, feel,
configuration, libraries, data files or functionality.


> Yes standards can be changed but you need power and market share to
> do that, Linux has little of either right now.

True, that's why we make such an effort to follow standards.


> If you want to see a great unix mailer (IMHO) but with an ugly
> interface checkout XFmial.  This is a Eudora clone with filtering,
> full POP support, message downloading by UID so those of use who
> read mail from different machines see all mail.  Fetchmail or
> fetchpop ignore a message that is marked read even if it has not
> downloaded it. DUMB!!!!

First of all, looking at a POP3 server from multiple machines is
discouraged behavior for performance reasons, to quote the RFC:

  ...users and vendors of POP3 clients have discovered that the
  combination of using the UIDL command and not issuing the DELE
  command can provide a weak version of the 'maildrop as
  semi-permanent repository' functionality normally associated with
  IMAP. ... When these facilities are used in this way by casual
  users, there has been a tendency for already-read messages to
  accumulate on the server without bound.  This is clearly an
  undesirable behavior pattern from the standpoint of the server
  operator.  This situation is aggravated by the fact that the limited
  capabilities of the POP3 do not permit efficient handling of
  maildrops which have hundreds or thousands of messages.

It then goes on to recommend that servers be set up with storage
quotas and delete messages as soon as a user donwloads it.

Secondly, if you are managing mail from multiple machines, it is a
very useful default, since it keeps mail that has been dealt with on
one machine separate from the mail dealt with on the other.

Thirdly, it is easy to bypass this behavior.  In Fetchmail, just run
it with the "-a" option.  I don't know what the corresponding option
is with Fetchpop, but I'm sure it has one.


> It should check to see if that mesage has been downloaded into the
> current mailbaox and if not grab it and mark it as read.  Again this
> is standard windows POP3 mailer feature that needs to be brought
> into Linux.

That is not a standard POP3 feature, and as I said above, it is an
actively discouraged feature.  Have you looked at the POP3 standard at
all?  Before you start saying what is "standard", it is helpful to
look up the standard.  Find it at
  http://www.faqs.org/rfcs/rfc1939.html

Best of Luck,
-Gleef