Re: Writing a GNOME mail client.
- From: Michael Schuerig <schuerig acm org>
- To: gnome-list gnome org
- Subject: Re: Writing a GNOME mail client.
- Date: Sat, 17 Apr 1999 18:59:38 +0200
At 2:47 Uhr +0200 17.04.1999, Miguel de Icaza wrote:
> Now, what do we need to make this a reality? Well, step number one
> is to make this project fun and reusing all of the nice code and
> infrastructure that we have developed over the past months.
I'd like to introduce step number zero: Getting clear about the use
cases the mail client ought to support. So far I've been disappointed
by most mail clients I've seen (not that many, admittedly). They seem
to assume that I want to store all messages in a single place, possibly
hierarchically structure. But that is actually not at all what I want:
I'd like to keep "stuff" in thematical locations. Say, I'd like to keep
everything that's related to Linux in one place, everything that's
related to philosophy in another. For me it's only of superficial
significance what medium the individual pieces travelled on. I don't
care if it's email, news, fax, or something I printed. I'd need to be
able to cross-link pieces, of course. And of course I'd like to ignore
the thematical organization and access messages based on recency: after
fetching mail and news I'd like to see what I've got, more or less in
the way common clients support; only, I don't want to be limited to
that kind of access.
> We need various modules in this mail program. Each module should
> be implemented as a CORBA object, exclusively because it allows us to
> upgrade different components and choose different implementations over
> time, without having to update the whole system.
Please consider a broader perspective. I take your comment to go in the
right direction, but I'd like to add an emphasis. The issue is not
about email messages, MIME, SMTP, POP3 or whatever. Granted, they will
figure prominently in the final realization, but they are technical
means to achieve another goal: communication. The email, news, and fax
clients I've seen so far all include some kind of address book. Indeed,
such a facility is highly desirable, but, please, I only need one of
those and more than that is going to be a pain in the ass. So, an
address book doesn't really belong to one specific client but is a
feature of the entire user environment. On the same token, a time
scheduler does not belong in an address book or the other way around.
Keep the components nicely separated, it even makes development easier.
Michael
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]