<Shields Up>
I really wonder if the mozilla team uses
the mail-news product on an everyday basis.
Hey! There's nothing wrong in fixing problems
that make your life easier before picking up
the bug list.
Don't tell me that you guys clean out your inbox
EVERY TIME you are about to close mozilla-mail-news.
GNU/Linux didn't make it this far, trying to provide
a great user interface that made it easy for
people to move away from windows. The focus was
and is always on a rock solid product. User interface
comes second. Useability/reliability is supreme.
In the near future I wouldn't be surprised
even a little bit, if AOL The Company decides
to rip out Gecko, leaving a worthless shell
of a program behind... indulging in its
favorite pastime of cutting corporate deals.
After all, mozilla and NS6 are too big for
most small net appliances.
Even now, I personally don't think its too
late to cut up the massive program along functional lines.
For starters here are the individual pieces which
SHOULD BE STAND ALONE executables.
1. Mail reader/viewer.
2. Mail fetcher (a simpler version of fetchmail?)
3. Mail-Mover (from one mail database/file to another).
4. Mail-compacter/restorer (in case of corruption, etc...)
5. Mail-optimizer (creates the index files, index entries must be
created for 'deleted/but-still-hanging-around' emails TOO!!).
6. Mail-sender (UNIX's 'mail' without the mail-reading capability).
So, a 'get-mail' button click in (1) invokes 2 (or its libraries, see
below)
followed by 'reloading'.
A drag and drop, (or a FILE-A-MSG action) will invoke (3) followed by
calls to (5) for src and dest mail databases.
Ofcourse, these individual executables are nothing but
a shell over the following libraries (corresponding to the above).
a.(1) GUI libraries - yuck.
b.(2) libpop, libimap, lib....
c.(3) libmailmove.
d.(4) libmailcompact libmailsalvage
e.(5) libmailindx
f.(6) libmailsend
g. libmail (reads a mail file or a mail database
-- better functionality available if an
index file is present).
h. Some 'iterator/analyzer' libraries to walk thru a mail
file/database.
Can't put a finger on an application, but ...
Bottom-upwards, you see a reasonably good acyclic graph of dependencies.
Real neat stuff would be to use CORBA or simply plain old
file locks to prevent simulataneous manipulation of the mail
files/databases by the above executables.
(Is CORBA part of Mozilla?)
Even if there's some mgmt 'guidance' that the application
should be monolithic, there is nothing to prevent you
from linking all the libraries together into the executable #1
while still creating the 'adjunct' executables (#2 thru 5)..
[end]
Sent via Deja.com
http://www.deja.com/
