Joe Strout wrote:
>> I *hate* HTML because it makes it much easier, on Windows, to trick
>> users or disguise malicious mail. It also makes it easier for most
>> users to put in pointless dancing smileys and other things that
>> sends me
>> into synaptic spasms resembling a stroke when HTML isn't "cleaned
>> up" a bit.
>
> I tend to agree, but my mom loves dancing smilies, so I think we'd
> better support them. (Hmm... anybody have an RB code to render an
> animated GIF?)
I've found that a good approach is to let the user send it, but let the
recipient MUA strip them out because it's a waste...in my opinion, of
course.
The user's happy because they think they've spread their fuzzy warm
happy feelings, and I'm happy because I'm still a curmudgeon.
Here's another idea for a feature. Highlight a word and right click,
and you get bring up a "function pane" windowlet that lets you do things
like look up the definition of the word you've highlighted to
double-check you're using the right word. Refer to an online dictionary
or something of that nature...configurable in the preferences somewhere
if you need to change the URL.
For the email storage format discussed elsewhere in the thread, the
flat-file/directory combo mentioned earlier has one really big advantage
>from my perspective. When something goes "wonky", as it inevitably
does, and you just can't spend the next twelve hours hunting the bugger
down to fix it, you can just wipe the individual folder holding the
corrupted data (or rename it), fire up the mail client again, and if
you're using IMAP it'll rebuild the structure again. Either each
account (and meta-info) would go into it's own database so you can
selectively wipe and rebuild data as necessary, or there would have to
be recovery/sanity tools available to fix the DB's if you go the DB
route. Otherwise, the file structure idea means there may be less
chance for bugs.
For reference, there is a recent document on QMail 10 years after it was
made (something like "thoughts about security" and had qmail and 10
years in the title) where the author said he avoided re-coding and
duplicating things that were already handled by the OS. By using files
he didn't need to code for permission to access particular information
whereas Sendmail had mechanisms in place to do what the OS could already
do and in the process introduced more bugs and security issues. I saw
the similarity when people brought up Spotlight and using flat files for
storage. Unless you're going to introduce nifty solid improvements, why
do Spotlight's job or hinder users from using that feature by coding
your own?
If you really wanted to use that approach, you could still use flat
files and have the mail program insert a metadatabase of information.
It would duplicate the messages since you've got a database and a flat
file system, but for end users OS tools could search and back up the
data conveniently (the flat files) and your improved (hopefully) search
features would still be available from the database meta-engine within
the application. Or this could be user-configurable to begin with.
Mail storage: database or flat-file. Make a proof of concept, test the
speed of the two, see which works best for a default, let the user
choose which to use.
Just more ideas to throw out there.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|