Re: Configuration
- From: Scott Tyson <tysons deepwell com>
- To: Walt Armour <walt blarg net>
- Cc: Gleef <dzol virtual-yellow com>, balsa-list gnome org
- Subject: Re: Configuration
- Date: Fri, 5 Mar 1999 07:27:50 -0800
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
/++++++++++++++++++++++++++++++++++++++++
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]