Re: Configuration

[Walt Armour <walt blarg net>]

On Wed, 3 Mar 1999, Gleef wrote:

> 
> 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.
>

Yup, seen that before.  Needs to get fixed.

 
> On Wed, 3 Mar 1999, Scott Tyson wrote:
[snip]
> >
> > 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.
> 

I don't know about you but I don't care to develop in a black hole.  If I
don't know where my application is going or who may be using it then why
am I writing it?  To fill some personal need?  Perhaps, but then I'm not
going to worry about making it an OSS project.

Sure, I may leave the commercial marketing to Red Hat and the like but I
still am going to do my part to "market" Linux as a geenral desktop OS.
Based on my experience and skill set that makes my part the development of
general applications that Joe User will want to use.

> 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.
> 

I disagree with your first statement.  I sincerely hope to see the day
where configuration of an end-user system is a trivial task.  The blind
assumption that configuration is hard and will always be that way is what
keeps configuration hard.  Keep in mind that I'm talking about end-user
configuration here (e.g. applications) not OS level global settings, BIOS,
and other such things.  And I believe that is what we should focus on
here:  how easy can we make it to configure a mail client?

As to your second point, yes, I agree that filtering is 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_.
> 

Agreed to the first point.  Again, on the last point, I think this is a
poor assumption.  I feel that it should be our goal (and possibly every
developer's goal) to make configuration easy.  Again, remember the level
of configuration we are discussing here.

> 
> > 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.
> 

I think a tool like this would be nice but I don't feel we can leave it as
the final solution.  As we mentioned before if Balsa includes filtering
you don't have to use it.  But I don't think we should cut out a
potentially large number of users by requiring procmail for a function
that is found in the majority of commercial email clients.

> 
> > 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. 
> 

Two responses:  Then you can continue to use procmail.  I'm not aware of
anything that we have discussed that would preclude that.  Second, while
it may be true that no GUI tool provides what you need now what is wrong
with thinking that some GUI tool may in the future.  Perhaps a filtering
system in Balsa could be something to target your needs.  Of course, you
probably wouldn't use it but, hey, it's a goal.

> 
> > 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.
> 

I don't see how adding filtering into Balsa will sacrifice any 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 beg to differ on this.  The only time I have seen filtering handled by
the back-end server is in corporate installations.  For the average home
user filtering is handled by the client software.  Since the servers we
plan on talking with (IMAP and POP to start with) do not enable filtering
we must provide it elsewhere.  I suggest within Balsa itself.
 
>  
> > 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.
> 

I believe the difference in opinion here originates with a differing goal.
I want Linux to become a huge, market-gobbling success.  For that we need
market share and that share will come from the existing user base (of
which the majority are Windows users).  To win share we must provide them
with the features they need (or think they need).  To do that we should
examine the feature-sets of existing clients (Outlook, Eudora, Pegasus) on
whatever platform they are on.

> 
> > 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.
> 

Agreed.  But we must offer at least the same level of functionality that
users expect (and hopefully more).  I feel one think we should definitely
avoid is doing some differently (and less functional) just because we want
to avoid looking like Windows.

> 
> > 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.
>

I whole-heartedly agree.
 
> 
> > 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, I so hated that.
 
> 
> > 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
>

I agree here and that is why I frequently point people to IMAP.  If they
want functionality beyond "download-and-delete" then they shouldn't use
POP.  If they don't have IMAP then they will have to find a client that
will kludge around it.


walt