Well, thank you for at least taking the time.

But it is completely wasted. You do not know enough to answer. The mail 
service used to be a simple Unix-to-Unix copy-file (UUCP) command. So, a 
file was transferred from one Unix server/client to another Unix 
server/client.  The various "Exchange" servers were made to mimmick what 
we invented in DS/ID - and Lotus Notes commercialised. This has nothing 
to do with the email client's functionality.

I know of IMAPs shortcomings - and it bothers me that you do not. How 
you implement the access to the ".sdb" files that is used by the email 
client is beyond my concern, but it is not SQL or not anything related 
to databases like Oracle, Ingres, Postres, or MySQL even.

Just that you consider this to be a "client/server" application exhibits 
just your level of competence. I have no doubt that you have programmed 
many years. I have also terminated employment of consultants that have 
programmed for many years when they insist that they know the truth, and 
do not want to listen.

The functional deficiency that I reported is where an object being an 
email with attachments and all arrives on the SMTP protocol, and what is 
done. The FTP and SMTP defines what is supposed to be done - it should 
be delivered by the MTA to the MUA - where the MUA is to show it 
according to certain conventions. I am not addressing these conventions 
- the MTU. The MTU can do a number of things, such as stripping off 
attachments, storing journal information, running rules - like as in 
Documentum or OpenText's LiveLink.

These applications may have included functionality that duplicates the 
message, forward it according to rules and place it in a "workflow" 
defined by the EDMS. Evolution is not there, but a simple rule can 
integrate with these systems. These systems are "servers" and run in 
another address space and can be moved around and run on other computers.

Evolution as a software piece may be designed in modules that interact 
using a published set of procedures that are linked in to its address 
space. But a library function has nothing to do with "clients" and 
"servers" - even on Windows. There are not "lots of different methods" 
to retrieve emails, there are just one and variants of this - and this 
(POP to POP3) are variants of the "telnet" protocol.  IMAP is another 
set of standards - but except for origin, is pretty similar.

MS Exchange is a way of storing emails in a central repository, similar 
to Lotus Notes. Microsoft has made their definition of how to access 
this, but this interface is like the Documentum MTU - an interface to 
show the emails that are stored in the MS Exchange.

If you move an email on a server, and this produce duplicates , you file 
a bug report to maker of the server. with MS Exchange, you file it with 
Microsoft.

In the case where Evolution uses plain vanilla Linux files that 
Evolution has made to hold the mail objects that are received - the 
error goes to Evolution. If the Documentum server also has to move it, 
and duplicates this effort, it is none of your concern. If MS Exchange 
hates this - it is none of your business. What is your business is to 
see to that no objects are lost and the number of objects held in the 
MTU is the same as the number of objects that has arrived subtracted 
what has been deleted - that the semantics are defined. Well, COPY means 
making a new object somewhere else, and I do not care how difficult this 
is. MOVE means that the object is to be physically taken from where it 
is stored and stored somewhere else - and I do not care how difficult 
this is. Then the integrity has to be retained, meaning that both the 
"COPY" and the "MOVE" must be verified before any temporary data is 
deleted, and should the operation fail, a proper message must be 
provided. An essential integrity constraint is the number of objects. 
With "Copy" this will increase by one, with "Move" it will remain 
unchanged. So since you "Move" by a initial "Copy" - all traces of the 
original must be DELETED (or "Expunged", "Scratched").

Otherwise, those that write the search library will be told there are 
"n" objects in the container ("file"9 - while there is "n+1". That will 
result in error messages to those that write the search algorithms - and 
you do not receive these, but they are on the net. I have read them.

You also risk "loosing" objects/emails, if you run a "Compacting" 
algorithm that scans the container for "n" objects, and copies this in 
ascending order to a new container - to delete the original container. 
The last email was not copied - not the last arrived, but the one that 
occupied the last slot in the container.

It is years since I programmed, probably in 2001. I am just a director / 
manager that has all these details that I cannot erase. Explain to me 
your problem, and most likely I have the answer. Your explanation of the 
MTA and MTU gave you this response. I understand that you try to keep 
one source code for to many mail repositories - while just really 
maintaining one repository. Now focus on the file system that Evolution 
makes - and forget about the rest. Forget about overhead, because in 
"servers" such as Documentum and Livelink, "Move" is a atomic operation 
- an update of an index - the object is never moved. If MS "moves" and 
Expunge" and turn their heads three times - who cares? Forward the error 
reports to Microsoft. Here "Copy" causes overhead - since that invoilves 
creating a new object that is a duplicate - so a unique new reference 
code must be generated that shows that the two are identical copies, 
just two instances of the same.

I know these details because I have managed huge projects, including a 
number of ports of Unix. I have written the indexing for both Oracle and 
Sybase - because they both had to be re-done when one of my projects 
exposed these products to real parallel processing. I have used 
consultants for most of the work - and the code is also part of the GNU 
open-Ingres, now "Postgres" code. I just managed Mimer - the origin of 
MySQL. My consultants have also worked for Microsoft on their SQL Server 
and upgraded this from Sybase. There are probably some million lines of 
code out there that I have produced on short periods - "because I had 
to". I have never used the "Mickey Mouse" products of MS - but Notes has 
been used on projects. The usual tools are however, the EDMS.

Yours
Knut H.

On to-16.09.2010 22:11, Paul Smith wrote:
> Ayeyiyi.  Knut, please stop trying to impress everyone with your
> credentials and consider that you might actually not know everything
> about everything quite yet, regardless of how much you know about
> databases.  I've been programming on UNIX since before POSIX even
> existed and I certainly understand the concepts quite well.  I'll post
> one last message in the hopes that others reading this will understand
> what's going on, at least.
>
> Since you've done a lot of DB work apparently, consider Evolution as if
> it were a generic open source SQL client program that can connect to
> lots of different types of SQL servers: Oracle, Postgres, MySQL, etc.
> The data is left on the server (for at least some of the protocols) and
> the client only provides access to the data.  The client can only
> perform the operations that the server makes available: you can't
> perform Oracle-specific SQL commands on a Postgres server, etc.  Suppose
> this client could also access databases that are local and don't have a
> server (sqlite databases maybe).  That's a good analogy for what
> Evolution is.  You didn't tell us what kind of server you're trying to
> talk to but people are assuming IMAP so I will too.  If you're using
> something different let us know: that would be very helpful information.
>
> First, SMTP is a mail *transfer* protocol.  It defines the network
> protocol for two mail *servers* (e.g., sendmail etc.) to talk to each
> other to exchange mail.  In SMTP parlance these are known as MTAs, or
> Mail Transfer Agents.  Evolution is NOT an MTA.  Evolution is a Mail
> User Agent (MUA).  The SMTP standard has virtually nothing to say about
> the "protocol" that MUA's use to talk to MTA's.  In short, Evolution has
> virtually nothing to do with with SMTP at all (Evolution has the ability
> to connect directly to MTA's to _send_ mail, but it cannot, and neither
> does any other client, use SMTP at all when _reading_ mail, as we are
> discussing in this bug).
>
> Second, Evolution as an email client actually can use lots of different
> methods to retrieve email.  It can get mail from a POP server, from an
> IMAP server, from a Microsoft Exchange server, or from a Novell
> Groupwise server.  It can even read from USENET.  And, of course, it can
> read from local mail spool files of various types.  One of these types
> is the traditional UNIX mail spool that sendmail uses, and others are
> spool files left by other types of local software.  Each of these uses a
> different protocol for getting mail.
>
> Third, Evolution does not implement the server software, at all.  If you
> connect to a POP server then someone else wrote that POP server.  It may
> not even be free software at all; your ISP (that you download your email
> from) decides all that.  Ditto for all the other ways Evolution gets
> email.  Even the local spool files are created by other software such as
> sendmail, etc., that Evolution has no control over.
>
> Fourth, for a number of those server types, including IMAP, Exchange,
> Groupwise, etc., Evolution does not manage your email locally.  The
> email is left on the server and Evolution sends commands to the server
> to ask it to manipulate your email.  This is what I mean when I say that
> the IMAP protocol doesn't support MOVE: you don't have a local copy of
> the email so only the server can manipulate it, and you can only ask the
> server to perform the commands that it supports.
>
> With other types of mailbox, such as local mail spools and POP servers,
> Evolution downloads your mail to your local system and manipulates it
> there.  Obviously in these environments Evolution has a lot more
> flexibility in the operations it can perform.
>
> Finally, WRT searching, searching is very safe, at least in IMAP.  Every
> addition to an email folder only ever adds to the end of the folder,
> never inserts in the middle, and every new message number is higher than
> any other message number (for that folder) that has been used before so
> there's never duplication.  Every change to the folder is atomic (you
> don't get half a message added, or half an expunge performed).  Every
> search starts at the beginning of the folder and goes to the end by
> first finding the current maximum message ID, then going through the
> folder message by message (ignoring missing messages) until that maximum
> is reached.  If new items have been added since the search started they
> will have larger message IDs and are not seen for that search.
> Alternatively sometimes the client asks the server for a complete list
> of message IDs, then goes through that list.  In any event, it's never a
> problem to have new messages added during searches.
>