Dear andy_21,
I base my answer on prior experience in application development and web
programming, as well as on research I have carried out for this question.
To answer one of your concerns, there is no need to set up a full
client-server system if your product consists mainly of a user
interface. All you are providing is the client at the front end, while
email delivery at the back end is supplied by the user's existing email
service, which is typically an ISP or a dedicated email provider.
When users install your client, they will configure it with their
personal settings, as instructed by their email service, so that your
client can talk to their server. You don't have to supply the server
yourself. Depending on how you go about developing the email client,
you may not even have to worry about implementing the communication
protocol between client and server.
One of the first decisions you will have to make is whether you want
to support one or both of the Internet Message Access Protocol (IMAP)
and POP (Post Office Protocol). The chief difference between these two
is in where a user's email messages are stored. In the case of POP,
the mail client transfers all messages from the email server to the
user's local storage space. An IMAP client, on the other hand, leaves
the messages on the email server, and is therefore not responsible for
storing or modifying the user's messages.
A client is simply a program that works in cooperation with
a server to share the work load of processing information. An
e-mail client combines the features of your workstation (Windows,
Macintosh, UNIX, etc.) with the server's connectivity to the
Internet or other network. Both POP and IMAP protocols handle
attachments easily and have address book and signature block
features.
[...]
IMAP is better if you need to access your mail from work and
from home, or while traveling.
Your e-mail and folders can reside on the mail server so your
e-mail and folders are accessible regardless of which computer
you are using.
[...]
POP is suitable if you are going to use e-mail only from one
location, such as your home or office, because all your e-mail
activities are performed on your local workstation.
Mail is ?popped? (downloaded) from the inbox of the e-mail
server to your local machine, either manually or according
to a preset time interval. The e-mail is stored on your local
computer where you can create folders that may or may not match
the folders you might have on the e-mail server.
Since the e-mail is normally deleted from the server when it is
downloaded, you are responsible for making backup copies.
University of Arizona: CCIT: Comparison Between IMAP and POP
http://computing.arizona.edu/help/email/imap_pop.shtml
The following document describes each protocol in greater detail and
makes a full comparison of their implications for the user experience.
There are three different paradigms for accessing remote
message stores (or "mailboxes"). They are: offline, online,
and disconnected. In "offline" operation, the mail client
program, or "mail user agent" (MUA), fetches messages from a
mail server to the machine where the mail program is running,
and then deletes them from the server. In "online" operation,
messages are left on the mail server and manipulated remotely
by mail client programs. In "disconnected" operation, a mail
client connects to the mail server, makes a "cache" copy of
selected messages, and then disconnects from the server, later
to reconnect and resynchronize with the server. In both online
and disconnected access modes, mail is left on the server, which
is important when people use different computers at different
times to access their messages.
[...]
It is the thesis of this paper that (a) supporting online
and disconnected access is essential for a growing fraction
of mail users, and (b) POP is inadequate for proper online and
disconnected support, whereas IMAP does a good job for all three
message access paradigms. This is not an indictment of POP, since
POP is entirely satisfactory for its intended design center of
offline mail processing. Rather, it is an explanation of the
importance of online and disconnected operation, and why IMAP
is a much better answer for those access modes.
IMAP.org: Message Access Paradigms and Protocols
http://www.imap.org/imap.vs.pop.html
If you decide that your email client only needs IMAP support and if
you want it to be a web application that users can access through any
web browser, you can implement your product on top of SquirrelMail,
a popular open-source webmail package. Application development would
then consist largely of web design, with SquirrelMail providing the
email mechanics. On the other hand, someone other than the user would
have to be responsible for hosting the completed application, because
you cannot expect your users to have their own web space.
http://www.squirrelmail.org/wiki/CustomizingSquirrelMail
SquirrelMail: Customizing Squirrel Mail
http://www.squirrelmail.org/about.php
Squirrel Mail: About
You can also get a pre-existing base for your interface design if you want
to implement it in a desktop application, which users would install and
run on their own computers. As luck would have it, the makers of Eudora,
a popular email client that resembles and competes with Microsoft
Outlook, have recently announced that they will be releasing Eudora
as an open-source package. Eudora is a feature-rich application that
supports both IMAP and POP. On the other hand, adapting Eudora to your
needs would likely require more technical sophistication than customizing
a web application.
QUALCOMM is announcing that its Eudora email program will become
an open source product effective the first half of calendar year
2007. As an open source product, it will be free to all customers.
[...]
The open source version of Eudora is targeted for release in
the first half of calendar year 2007 and will be free of charge.
Eudora: Announcement FAQ
http://www.eudora.com/faq/
Eudora: Home
http://www.eudora.com/
Another powerful open-source email client is Thunderbird, distributed
by the same group that is responsible for the Firefox web browser. You
can make a skin for Thunderbird, here known as a theme, with relative
ease. Deeper changes in the behavior of Thunderbird, whether by writing
an extension or manipulating the core program, would require sophisticated
programming skills.
Mozilla Developer Center: Thunderbird: Theme Packaging
http://developer.mozilla.org/en/docs/Theme_Packaging
Mozilla Developer Center: Thunderbird: Extension Packaging
http://developer.mozilla.org/en/docs/Extension_Packaging
Thunderbird: Home
http://www.mozilla.com/en-US/thunderbird/
A further possibility would be to commission a customized version of
the email client Emma, a Windows desktop application formerly used by
MCI's commercial email service.
Emma is an email client for Windows that we offer on a customized
and OEM basis. If you want an email client customized for your
organization, look no further. If you want to develop your
own email client, please consider licensing Emma as a base to
work from.
Pete Maclean: Emma
http://www.maclean.com/emma/
You might also work out a partnership with the author of the Scribe
email system.
Scribe has a plugin interface that allows people to expand the
capabilities of the application. If anyone is interested in
writing a plugin I can send you the libraries and documentation
to do so. So far you can write plugins for 3rd party MIME type
viewers, directory services and text handling utilities. In the
future Scribe will support plugins for mail source/sink and mail
storage. Which will mean that the very core of Scribe will be
open to new ways of receiving, sending and storing email.
i.Scribe/InScribe Email Client: Home
http://www.memecode.com/scribe.php
I wish you all the best with your venture.
Regards,
leapinglizard |
