Re: [Michael Bacarella <mbac nyct net>] GNOME architectural suggestion..
- From: Alexandre Owen Muniz <munizao cyberhighway net>
- To: gnome-devel-list gnome org
- Subject: Re: [Michael Bacarella <email@example.com>] GNOME architectural suggestion..
- Date: Tue, 06 Apr 1999 09:10:05 +0000
> Wouldn't this be easier if you could just tell the user "ok, click START,
> click Internet, click E-Mail, click Configure" and once they set it all
> up, it is stored in a standard location. Then, when the user goes to check
> their mail, the e-mail client will just load the config from the system
> and handle it transparently?
This is essentially what MacOS 8.x does, and it is quite slick.
(Speaking as an ISP tech support guy.) A problem is that for the mail
clients I've seen, the configuration dialogues generally allow you to
override the global email settings, (which is good,) and don't allow you
to change the settings unless you choose to do so, (which is rather
bad.) But this is just a client issue.
> Nobody wants this user to call back and ask for help once they install a
> new e-mail client.
> My proposal:
> The GNOME Unified Mail System
IMO, this would be best done by using a Linuxconf module for accessing
the mail settings, and adding a wizard interface. True, this would not
be OS-portable, but it would allow the mail configuration to be accessed
via any Linuxconf interface, which would be a plus. And is there any
reason why Linuxconf cannot be ported to other *ixes?:) I also agree
with Steve Homer that the underlying configuration should not be part of
the desktop environment. As a practical matter, KDE is going to be
around for a long time, and a system that lets one seamlessly switch
from a KDE mail client to a Gnome mail client will be of benefit to
users of both desktops.
The "right" way to do this would be with a Linuxconf module for
fetchmail, which has a nice rc file for Linuxconf to work on, and which
would allow any mail client configured to get mail from the local spool,
(which they should all be by default,) to be automatically using this
system. Failing this, a gui wizard to write a .fetchmailrc without using
Linuxconf would have more portability at the expense of losing all of
the other Linuxconf interfaces. (There is no reason that both solutions
could not be pursued simultaneously.) Fetchmail has a lot of
fuctionality that would have to be left out of this system, but the
people who are using it can take care of themselves.
> * Less codewriting equals less chance of writing
> buggy code. (you know, the kind that crashes
> programs other code hard?). Not to mention that community
> scrutiny will be focused on this one piece of GNOME,
> rather than hundreds of variants of it that a user may
> or may not use.
Using programs that already exist and work well means writing very
litttle code at all. :)
] [Thread Prev