Comment 24 for bug 365270

  I will refrain from commenting on your skills.

For move: Please study available literature - such as SVID / POSIX
"Memory()". These documents are integral to the Linux definition.
Evolution is an Email client according to the SMTP protocol - and not
the IMAP. IMAP is another functionality.

If IMAP cannot do a MOVE without a heavy load on both client and server,
then the server side needs to be modified. If they do not want to do so
because it is a heavy load - it is like saying "I do not want to cross
the road, so the store has to move to my side" - let them just say so,
and produce more unreliable software. If the specification is the source
of the excessive load - then change the specifications so that they make
sense. Like you you may use a "memcpy(s.d.n)" with a subsequent
"memcmp(s.d)" instead of a simple "memmov(s,d,n)" - everything is in the
same address space (so where is the "client" and "server"?). SVID never
refers to "Expunge" not does Posix. So, get on and make the software
instead of arguing.

Regarding searches - you can rest very assured that as long as the
software does not know where to search and when to stop it, objects will
not be found. Please study chat's. If you do not know what "cardinality"
is, go back and study e.g. Don Knuth: "Fundamental Algorithms" ,
"Sorting and Searching". Nothing has changed since he wrote those
volumes. if you need further references about me - call Chris Date at
Stanford.

I have the succesful implementation of indexing in 5 industry standard
databases underneath my belt. You have done none, and claim experience.
If you want experience, get on doing it. When you outperform Oracle, MS
Sqlserver and Sybase and a couple of others - you can claim my
experience, until then, you listen and try to learn.

Unfortunately a company has introduced a generation of so called "knows
how to do it" that can receive a a certificate for the skills in
exchange for a small sum.

It all boils down to so called self-acclaimed "specialists" that claims
to know things and have read a pile of document and never coded a system
in their life. Please stay away, if the software is to be usable by
others, errors needs to be fixed, and not argued.

To a system, a bug is CRITICAL if it makes everyone leave the software
and use another package. How would Oracle survive if it contained a bug
that required everyone to use Sybase? The move is very easy from
Evolution to Thunderbird - so just drop Evolution in Ubuntu and use
Thunderbird with Lightening instead. Thuunderbird can implement Move
Copy, Expunge - and a lot of other things, so why waste your breath
arguing? RIP Evolution - your early demise was caused by because of
silliness and incompetence. What might have been, will never be.

Knut H. flottorp

On to-16.09.2010 01:39, Paul Smith wrote:
> I'm loathe to get involved here since Knut seems intent on flaming and
> not so interested in understanding, but reading the comments here I've
> been struck by a great attention to irrelevant details and not much
> clear description of the real issue.
>
> Knut continually makes reference to a "MOVE" operation, as if such a
> thing existed. But it doesn't. If it did, you can be sure that
> Evolution would use it.
>
> Why can't Evolution create that operation? Because Evolution is a mail
> CLIENT. It talks to mail SERVERS. Evolution does not implement and
> cannot influence the servers. The only operations that the client can
> perform are those that the server supports. The servers implement the
> IMAP standard, and the IMAP standard does not define a MOVE operation.
> So, no IMAP server supports a MOVE operation, and so no IMAP client can
> use a MOVE operation.
>
> So good, there's no MOVE operation. The only way an IMAP client can
> effect a move from one folder to another is by first doing a COPY, then
> marking the original message as deleted, and this is what Evolution and
> ALL OTHER IMAP CLIENTS (yes, including Thunderbird) do. That by itself
> is enough to blunt some of Knut's criticisms, since no client will ever
> be able to avoid the creation of a new message via the COPY command.
>
> Similarly, the IMAP standard does not provide any way to delete a single
> message. The ONLY way to actually cause messages to disappear out of an
> IMAP folder is by an EXPUNGE, which takes all the messages that have
> been marked as deleted and removes them (not just one, but ALL of them).
> This is a very expensive operation, typically, for your server (as
> opposed to marking a message as deleted which is typically very fast).
> After the expunge is done, then often the client has to re-read and re-
> index the messages, because its local cache of which messages are marked
> deleted and which aren't might be wrong. The whole thing is very labor
> intensive on both the client and server, as well as the network.
>
> Evolution works the way that the IMAP standard writers intended clients
> to work: it hides deleted messages and leaves the decision about when to
> expunge them up to the user.
>
> The problem is that many other clients don't work like this. They don't
> hide the deleted messages, which leads to lots of confusion about
> duplicated messages, and they also expunge messages "for" you. For
> example other IMAP clients implement the semantics of MOVE by doing a
> COPY, marking the original as deleted, then running EXPUNGE. For every
> single email you delete. This is a big load on both clients and
> servers, AND it means that your email that you might have deleted but
> not wanted expunged yet, is deleted for you.
>
> This is a shame because if all clients worked the way the standard
> expected them to then they'd work together well. However, just like
> Evolution cannot change the way servers work, so it cannot change the
> way other clients work. So, or course Evolution should have an option
> to behave the way other clients do and have a physical trash folder and
> implement the COPY/delete/EXPUNGE semantics that other clients favor.
> You won't need this if you only ever use Evolution as a client but if
> you switch between different clients you may need it, and Evolution
> should provide that support. I believe they intend to but obviously
> this is a low priority, based on how long these bugs have been open.
> That's definitely a shame.
>
>
> As for Knut's other comments, he implies above that he read and understood the RFC Marc mentioned but that is clearly not the case. There's no such thing as "cardinality of indexes" in email, and there's no chance that searches will skip anything. When you do the COPY the message number on the copy is the next number in a monotonically increasing index, it is NOT "inserted" into the middle. When you EXPUNGE all deleted messages disappear and their numbers are gone, and NEVER re-used. There is no chance for confusion of duplicate message numbers, etc. during sorting or searching.
>