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.
>
--
Move is Copy + Thrash, should be Move that removes all traces of the first.
https://bugs.launchpad.net/bugs/365270
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
