Stefano Bagnara wrote:
Is there really a good reason to have protocol specific code
in the MessageStore/Repository layer?
Sure, PERFORMANCE is the good reason.
The simpler interface is a key=>stream association but we will not able to
provide good performance. When looking up only for message size or for the
subject.
It's more than that. When a client selects an IMAP mailbox, the server
must tell it the number of messages flagged, existing, recent, unseen.
These need to be *fast*. When an e-mail client starts up it might ask
for these statistics over most or all of the folders that the user has.
It is so important to be focused on IMAP performance from the beginning,
IMHO. Not necessarily for SEARCH but for SELECT, IDLE, FETCH, etc.
A generic message interface would abstract the protocol
specific code entirely, leaving it to the protocol handlers.
We don't have to support 3000 protocols: mail is read in POP3 and in IMAP.
IMHO we should try to provide efficient ways to use that 2 protocols.
In fact you really just need to efficiently support IMAP. Because then
POP is just a trivial subset. In fact when I was implementing an IMAP
server (which I never completed) I implemented high-performance POP in
just a couple of hours.
Do the client runs query over this attributes?
I believe so. Through the "SEARCH" command...
http://ietfreport.isoc.org/idref/rfc3501/#page-49
I would like also to know what are the SEARCHes really implemented and used
by commonly used mailers. The 'A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM
"Smith"' seems to me very powerful but I guess how much IMAP clients let me
perform this kind of search on the server.
Based on real usage I would create a repository containing the needed
columns.
Thunderbird lets you create arbitrary searches and save them as
folders. (They don't support nesting or OR-ing though.)
I think you at least need to support SEARCH fully to consider yourself
IMAP-compatible. However you might decide not to make SEARCH very
performant.
Are this attributes sent to the client without the body?
Yes. See FETCH
http://ietfreport.isoc.org/idref/rfc3501/#page-54
The message header only, body only, flags only, etc.
can be fetched.
I also see 'A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])': what
are the standard/most used field set in this queries?
IMHO we need to consider real cases to be able to do something performant.
I have some real-world traces somewhere, I will dig them up and send
them to the list.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
