Re: Configuration

[Walt Armour <walt blarg net>]

Okay.  We could argue configurability vs. flexibility vs. the unforseeable
future until the cows come home.  If anyone wants to get together over a
beer it would probably be an excellent discussion.  :)

But for now I think we may have settled toward a slight kind of
aggreement, sort of.  :)

Including filtering in Balsa is not A Bad Thing (tm) but we do need to
determine how much filtering is needed.  In my mind sufficient would
probably be things to the effect of "move messages from X into this
folder" and "if subject contains Y, delete it".  If people want the power
of a small country for filtering then they can break out and go to
procmail.:)

walt

 On Thu, 4 Mar 1999,
Gleef wrote:

> 
> On Thu, 4 Mar 1999, Walt Armour wrote:
> > On Wed, 3 Mar 1999, Gleef wrote:
> > > 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.
> 
> I'm not saying not to care about who uses it.  I've seen projects whose
> goal was to make a good program, I've seen projects whose goal was to
> crush so-and-so, and I've seen projects whose goal was to copy so-and-so.
> Generally, the program produced was better if focus is kept on making the
> program good, rather than focussing on the other guy.  Of course making
> the program good includes keeping an idea of the target user, and what
> they want to do.  I doubt Balsa's target users want a clone of Outlook.
> 
> 
> > 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.
> 
> That's fine.
> 
>  
> > > 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?
> 
> Personally, I hope configuration is never a trivial task.  The ideal
> configuration complexity varies directly with system flexibility.  What
> this means is to make a system trivial to configure, you must make it
> inflexible.  This is regardless of whether the system is an application,
> an OS, or a toaster.  That's not to say you can't make an inflexible
> system HARD to configure, but you certainly can't make a highly flexible
> system trivial to configure.
> 
> That being said, systems like Procmail some unnecessary complexity, and a
> lot of seldom-used complexity, that can be avoided with a good frontend,
> so it can be made easier to configure.
> 
> 
> > > 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.
> 
> Configuration needs to be as easy as possible, but I don't want to see
> useful features dumped just because it will make configuration harder.
> I'm saying that beyond a certain point, configuration can't be made
> easier without dumping flexibility.  That being said, your point below has
> convinced me that having some filtering features built into Balsa would be
> a good thing for some users, and additional flexibility could easily be
> added by using Procmail with Balsa, without Balsa requiring Procmail be
> installed to access some common filtering features.
> 
> 
> > > > 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.
> 
> True, there's nothing preventing a user from using something like Procmail
> anyway, regardless of whether or not Balsa does filtering.  There will be
> users who just can't get Procmail on their system, and they needn't be
> left in the cold.
> 
> 
> Gotta go
> -Gleef
> 
>