Re: Writing a GNOME mail client.


you're not talking email clients here.  You're talking something much
broader.  Something almost yahooish.  Organized data storage mechanisms.

Maybe that's something we need to turn our thoughts to as a group.

How can we organize the data in our life in the most flexible and easy
to use manner?  for all sorts of different meanings of "easy to use".

Maybe an architecture like this would be a start.  This is rough, I'm
working this up just out of the shower. :)

                           Message Storage System
A Message is any document (email, image, raw text, URL, etc)

Each message stored is given a unique ID.  (Basically, a public dB key
if you will).

Each Message may be tagged as belonging to any number of subject areas.
	In the common case, most Messages will only belong to a single
	subject area.

An index of each subject areas will be maintained on the fly.  However,
this index needs to be able to be regenerated from the Messages 
themselves in the event of an index corruption.  This means we'd need to
store the tagging with the Message.

Standard dB tools should let us build something like this.  We could even
make default 'Themes' of subject areas for folks who really don't feel
like taking the time to create their own.

We'll probably find ourselves needing to use gecko or something like it
for the display engine of the various Messages, since it can handle a
whole lot of data types.

Am I just whizzing in the dark here?  Or does this sound like a decent 
aproach to this problem?


On Sat, 17 Apr 1999, Michael Schuerig wrote:

> 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
> -- 
>         FAQ: Frequently-Asked Questions at
>          To unsubscribe: mail with 
>                        "unsubscribe" as the Subject.

Scott Wimer
play  --->
work  --->

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]