Thank you for explaining it so elaborately.
So, If a new message comes in through SMTP and is stored in database, how
are the IMAP client informed about the new messages.
Is it handled through database triggers.
If not, what is the meachnism used to inform the clients about a new
message, deleted message or message state chage.
From: Geo Carncross <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED],DBMAIL Developers Mailinglist
<dbmail-dev@dbmail.org>
To: DBMAIL Developers Mailinglist <dbmail-dev@dbmail.org>
Subject: Re: [Dbmail-dev] DBMail synchronization
Date: Tue, 29 Mar 2005 18:15:07 -0500
On Tue, 2005-03-29 at 13:43 -0800, gopalakrishnan kamalanathan wrote:
> I want to know on how the synchronization between two email clients in
done
> in DBMail.
That's not DBMail-specific. That's IMAP-specific.
They don't synchronize with eachother- they synchronize with a [remote]
message store.
> Is the synchronization done in the database? Or does the processes
handling
> the EMail client talk to each other for synchronization?
I think you misunderstand how IMAP works.
IMAP clients share a message store. They might use caching to speed up
lookups, but they always ask a single server [unit] about the messages.
IMAP clients are not synchronized unless they run without a cache and
are presently performing no operations [and no new mail has come in :)]
But those things are on the order of seconds. People don't worry about
mail being synchronized on such small orders.
IMAP servers [generally: e.g. Cyrus MURDER] don't synchronize with other
IMAP servers.
So IMAP clients and IMAP servers have nothing to do with
synchronization. Lookout!/Express calls what they do with the IMAP
server "synchronization", but it's really not IMAP-specific, as it's
synchronizing a CACHE and not really any different than a web browser
doing an If-Modified-Since header.
It's helpful to think of IMAP as a really, ungodly, horrible, nasty,
[ahem], remote filesystem.
Like NFS, or HTTP+DAV. Only, _unlike_ NFS or HTTP+DAV, it doesn't serve
_files_ (although it could), it serves mime message parts or mime
messages. It also allows a certain level of annotation to occur
(flags/keywords).
Now.
IMAP was adopted by a large number of people who are masochists and
didn't understand the level of involvement in keeping a message-store
and a client's narrow-view of it in-sync. Thus along came IMAP4, and
IMAP4rev1 because Mark Crispin didn't want to admin IMAP4 was a bad idea
too.
rsyncing a maildir or MH folder, and unison-merging a list of
annotations probably would have made much more sense had anyone decided
to have sense about it. They didn't, and so we don't.
That said, DBMail actually understands these costs, and realizes IMAP is
here to stay. It alleviates these costs by being both ends- by being the
concept of a message-store, and the method by which a client keeps it in
sync (IMAP).
Like CYRUS, now that I mention it, in many respects.
But unlike CYRUS, I think the DBMail people understand that making a
robust message-store is hard, and best left to people who actually do
that sort of thing [MySQL, PostgreSQL, etc].
As a result, under finely cooked circumstances (reality), DBMail will
kick the snot out of Cyrus or UW-IMAP in some wonderful scenarios that
occur REALLY frequently for web-based and small-device IMAP clients
[like my PALM].
But IMAP is here, and while my rsync/unison mailbox will likely never
catch on, DBMail does well enough.
> If there is a some other client which accesses the message store other
than
> IMAP client? then how does the synchronization works?
The problem remains the same, with the exception of Postgresql and a
direct database connection- at which point, Pg's native concurrency
systems take over. Generally, one client blocks. For the most part, this
synchronization takes place on the order of milliseconds, so you need
not be bothered by this.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
