Re: Configuration

[Scott Tyson <tysons deepwell com>]

I agree with this.  Basic filtgering on from, top, cc and subject wouild be more than adiquate.  Also having the ability to combine fields into and/or agruments wouild be great. 

On Fri, 05 Mar 1999 01:26:04 Walt Armour wrote:
> 
> 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
> > 
> > 
> 
> 
> -- 
> 	FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail balsa-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.

/+++++++++++++++++++++++++++++++++++++++
/+ Scott Tyson "RaEl"
/+ tysons@deepwell.com
/+ ICQ# 125581
/+ http://www.deepwell.com/~quake
/++++++++++++++++++++++++++++++++++++++++