Re: Writing a GNOME mail client.

[Michael Schuerig <schuerig acm org>]

At 20:33 Uhr +0200 18.04.1999, Steve Luzynski wrote:
> On Sun, 18 Apr 1999 12:22:03 you wrote:
> > Exchange has the ability to export to both imap and pop. Lets not
> > implament mapi suport and just use open standards like imap and pop...
> > exchange will be useable if it is configured to be open and standard
>
> How about implementing all mail retrieval protocols as pluggable
> modules? Then if someone really wants MAPI support they can code it up
> and drop it in.
>
> Would make for a wonderfully extensable client, actually.

Although it might sound odd, I'd like to suggest _not_ to do this. :-o
I take it, your point is that you'd like to get your mail through any
weird protocol whatsoever without having to care for it much.

If there's been any general point to the few messages I've posted to
this list then it is the suggestion to start from the desired user
experience. The technology will fit into place later. Don't start with
protocols, plugins, whatever tech stuff. Instead start with what you
want to do with a system.

So, let's see. Fundamentally, we'd like to receive and send message.
What protocol they happen to travel by is a more or less accidental
feature; ordinary users hardly like to care about it. Of course, this
user experience has to be realized in some way and there protocols will
figure. And there using a plugin architecture is a proven solution --
but a misbegotten one. One case in point is Netscape Navigator. I've
never tried to count the number of plugins available for it, but there
are a lot. So, you get each and every plugin you need to watch the
latest achievements in spiffy web design. But some time later you
realize that all those plugins don't help you one bit if you want to
use them outside of Netscape. Try to use a Netscape plugin to put a
shockwave animation into a spreadsheet, say. No way. The spreadsheet
developer could have implemented the Netscape plugin interface and the
X interface and the Y interface and yet another interface. This starts
to look as if it's the wrong way around. It's really not an individual
application's job to care for plugins. Instead, let applications (or
rather components) offer services and depend on services. The wiring
should be done by a general facility. (Did I hear anyone say
"OpenDoc"...;-))

Michael