Re: [Evolution] Spamassassin, Junk/Not-Junk, Training

[Jeffrey Stedfast <fejj ximian com>]

On Mon, 2004-04-26 at 11:09 -0700, Eric Lambart wrote:
[snip]
> What is the Ximian fascination with vFolders, anyway?  They certainly
> can be useful for organizing one's mail on a specific machine, but AFAIK
> they have no relation to the IMAP standard and thus just remind me of
> some sort of MS-style proprietary invention that leaves everyone else
> (who uses different software) in the dark.

you mean like physical Trash and Junk folders would be on IMAP as
well? :-)

different clients will have different names for those physical folders
as well, so what you are arguing for is just as broken as what you are
arguing against.

And... the author of the IMAP specification actually envisioned "Trash"
not being a physical folder anyway (hence why the IMAP spec does not
define one) and that clients would either display a message-list with a
flag set (a strike-through in our case) or provide a virtual Trash
folder (which we also provide).

if you read the whole discussion on the IMAP forums from years back,
there were some complaints by IMAP client authors because they weren't
as ingenious as we (mostly Zucchi) were and so weren't able to implement
vTrash as efficiently as we did :-)

Just because other IMAP client authors were incompetant doesn't mean we
should implement it the same way they did :-)

>   I realize they slightly
> speed up some actions like deleting, etc. but with a multi-threaded app
> is it really that much slower to command the IMAP server to copy deleted
> messages into a REAL Trash folder

yes, because the IMAP backend can only process one thing at a time
(hence only one thread can be doing something with the IMAP server at a
time).

> , and copy "junked" messages into a
> REAL Junk folder?

same as above

>   After all, that's a server-side action and doesn't
> require local processing time at all.

but it does require more round trips and can indeed require client-side
processing.

>   This would make the system much
> more useful in the real world, where people don't have the luxury (even
> if they wanted to) of using the same mail client on every machine.

this is all in your head (and/or crap IMAP clients)

> Via Squirrelmail, when I delete messages, it doesn't appear to happen
> any slower than Evolution's misguided and controversial idea of having a
> "virtual Trash" folder,

squirrelmail is a local process on the IMAP server itself. Evolution
does not have that luxury. so this isn't really a fair comparison.

>  which I and many others have complained about
> before.  When Evolution automatically filters messages from my INBOX to
> one of my numerous subfolders, the messages get copied very
> quickly--and, as they should be with IMAP, they are merely *marked*
> "to-be-deleted" in the source folder.

and...?

> I guess claiming Evolution 2.0 that has support for built-in "spam
> filtering" will look good in a Novell Press Release, but I'm sad to see
> it's been implemented in a way that seems so useless, at least to me
> personally.

useless to you does not mean useless to everyone else. Mozilla works
similarly to Evolution, as does Apple's Mail.app as far as spam
filtering. They don't move messages to another folder either, they
simply flag the message and leave it in the INBOX (or where ever).

Since there's no universally accepted IMAP flag for "spam", each client
is on its own.

Jeff

-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
fejj ximian com  - www.novell.com