On Fri, Jan 22, 2010 at 8:52 AM, Stefano Bagnara <[email protected]> wrote: > 2010/1/21 Robert Burrell Donkin <[email protected]>: >> i think that using sieve to deliver IMAP mail is wrong. i think that >> the script should set attributes on the mail (for example, set a >> attribute for folder) and with independent delivery. > > 5 years ago I was proposing > (http://markmail.org/message/xkcttgyqmfwpieew) to use a "destination" > concept for moving mails around. I think we could use special email > addresses (and maybe "forward paths", with reference to the "old" > source routing stuff) so to still keep working with mail envelopes > (even using a distributed email processor, as multiple james servers) > or alternatively using urls. The fact is that "state" is not enough to > deal with message routing so we need something more in the mailet api, > and we can do this 2 ways: A. add routing methods, B. add some more > expressive property than state.
sounds very interesting. could you write up the design more fully? >>> But I think you are right, the current MailRepository stuff is really >>> bad in terms of Performance. >> >> here's the issues which spring to mind: >> >> 1. the POP3 protocol stuff is sound enough but MailRepository insists >> on instantiating heavy mail objects which kills performance for IMAP >> (my server died several times a day before i ripped out this feature) > > The Mail object should not be so heavy as it tries to lazy load stuff. > But I'm not against changing the way it works. the lazy doesn't help in this case - IMAP just wants the meta-data or the raw bytes. >> 4. there are subtle semantic differences between the meanings of flags >> in POP3, SMTP and IMAP > > Can you give more detail? I'm not sure I understand POP3 and SMTP "flags" ... eg semantics of POP3 flagged delete is different from IMAP flagged delete which is different from JavaMail. all subtle but really annoying. IMAP has some stuff which are sort-of-flags which come from the SMTP envelope. JavaMail's usage isn't compatible. >> 5. there are subtle differences in rules between a POP3 INBOX and an >> IMAP INBOX. not a problem to resolve but the code needs to understand >> whether it's been used for IMAP or POP3 so it can behaviour correctly. >> i think that this prevents the use of a single functional API. > > I need details on this too. POP3 does not have big requirements. > It needs to be able to retrieve a list of message returning a "name" > (persistent) and a size. Do you think this is hard to expose via an > imap capable mail store? Or you are thinking of a mailbox api dealing > with protocol stuff like "pop3 session", "deletes at the end of the > session", "session sequence number for messages". At a glance we can > deal with sessions at the protocol level using a very simple data > access api. i'm thinking about the very basic operations like getting a list of emails in a mailbox, gaining streaming access to raw data and then modifying POP3 flags so that mail deleted as far as POP3 is concerned. >> my thinking is along the lines of: >> >> 1. introducing a new messaging style interface specifically for mail delivery > > Are you referring to the MailServer interface or an interface for the > "Mail Envelope". With "Mail Envelope" (again something that I was > discussing 5 years ago in the previous thread) the concept that we > should separate the mime stream to a Message object and the smtp > envelope to an envelope object and then reduce the mailrepository to a > "message" repository and spool envelopes. > > So, at low level we could have an incoming message to be > envelope+message.. smtp prepare the envelope object and stream the > mime to a jcr content. Then puts the jcr url in the envelope and put > the envelope in a jms queue. Then we move the envelope from queue to > queue. > > Am I going off topic or is this what you had in mind with "new > messaging style for mail delivery" ? not so much off topic as further than's achievable in the time window i have available just thinking of switching to a different interface for >> 2. introduce an efficient, simple, streaming POP3 backend API which >> can be adapted to MailRepository or other mailbox designs. performance >> for MailRepository would still suck but the OpenJPA (and potentially >> JCR) backends from IMAP could be used without heavy adaption or >> performance loss. > > IIRC I read multiple times that the current mailbox api is not great > for imap: I don't know the imap stuff enough to make any statement on > this but I'd like to understand if you think the goal is to improve it > by making it more "imap oriented" or improve it by making it more > "simple". I remember in past Joachim tried to explain me that imap > reference emails with 3 types of identifiers and this make almost > impossible to write a simple api for the message store: do you agree > with joachim on this? if you regard it as a store then yes i believe other styles of API are possible. i think that a minimal POP3 specific backend API could be adapted to both MailRepository and IMAP. IIRC POP3 just needs to know which emails are in the folder, stream out raw emails and flag or mark mails in certain ways. all the session management and protocol management foo would remain in the POP3 module. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
