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
I use Thunderbird and it has "Junk mail Controls" built into it and will move any spam into the Junk folder automaticly. As mail is being downloaded, the spam shows in your inbox, but then gets moved to the Junk folder after all the mail is recieved. You have to "train" it by marking the spam as junk, but after a short while, it works very well.
--
Brian Craft
Yahoo Instant Messenger ID: bcraft67 AIM: linuxman67 Website: http://userdata.acd.net/javaman67/ Linux Counter id: 97873 Linux......the OS of Choice!
_______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
