Pierre,
I'm starting to lose my religion on these ultra-generic repositories.
Why? Searching. I know the beauty of generic object storage is that I
can store anything and everything, but in our case, I only want a single
Class type to be stored in a given repository. And then based on that
and how it's being used, I need to be able to search those messages.
Here are some examples...
Ok, we are always storing MimeMessages, or ServerMimeMessages to be
completely accurate (the work around of the pro-client parts of
JavaMail). This is true for the mail SMTP delivery queue, the deferred
delivery queue (if indeed we separate these), the POP3 mailbox, and the
IMAP4 mailbox. For the SMTP queue, that's basically just FIFO, although
theoretically you might want it FILO, and maybe you let someone
configure that for whatever reason. But then more seriously, POP3
mailboxes and IMAP4 mailboxes. In POP3 mailboxes, you now introduce an
ordering, so you need to retrieve message #7, and delete message #5, and
then someone closes their connection, so the messages get removed if
appropriate, and then renumbered (as messages probably got deleted).
And the IMAP4 is a whole ball of problems as there's a searching
language you have to support. How will the generic repositories
efficiently handle this?
Another thing on the message object primary key... at one point we had
given it the message-id should be the primary key, and then for certain
delivery issues, that shouldn't be the case. Well, I've found a more
compelling reason we need to make it something more than that... certain
mail servers I found will deliver the same message multiple times to
different recipients at the same mail server. So instead of doing:
MAIL FROM: ...
RCTP TO: [EMAIL PROTECTED]
RCPT TO: [EMAIL PROTECTED]
RCPT TO: [EMAIL PROTECTED]
DATA
QUIT
they do...
MAIL FROM ...
RCPT TO: [EMAIL PROTECTED]
DATA
MAIL FROM ...
RCPT TO: [EMAIL PROTECTED]
DATA
MAIL FROM ...
RCPT TO: [EMAIL PROTECTED]
DATA
I finally realized this was happening this past month, and it explained
why only 1 person would generally receive a given email from this news
service. Very frustrating bug to find. This obviously seems like
something is wrong, but I don't know if it violates the spec at all.
One hack I was thinking of doing... you really need to get the primary
key of a message object from the message object itself... so I was
thinking we should do this: msg. setHeader ("X-James-Primary-Key",
calculatedKey) upon receiving the message, and then before we show it to
anybody (relaying, displaying in an inbox, etc...), we remove it. This
might not be the best OO approach to this, but I think it is pretty
logical to store the message with some meta data and then remove the
meta data before passing it on. Anyway, just a thought. I have the
week off (woohoo!) so if I get the time, I hope to spend a good day or
two bringing James to a useble state again.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
