Hi Benoit,
Thanks for the response. I'm all for extensions mechanisms rather than
using db schemas. If I understand what you are describing, and I can
make it work, it's going to be a much simpler solution than the hack I
put together a few years ago for my v3b5 installation.
Just to make sure I'm hearing you correctly...
1) I recognize (in a "ToFolder mailet") that a particular email is one
that I have a need to track and locate later.
2) I use the MessageId property on that email and externally store that
MessageId: "abc" is stored in mail account folder "xxx/yyy". (and "abc"
is a universally unique id across my James installation, correct?)
3) I write and register a MailboxListener to monitor all mailbox folders
for this account
4) The user decides to move message "abc" to folder "/archive2019/xxx/yyy"
5) My listener recognizes the id and updates my external registry that
"abc" is now in a different folder.
I've got to dig in and learn about writing a MailboxListener. But
assuming my assumptions for the steps above are valid, I can make it
happen. If I don't have the steps correct, please set me straight.
It looks like my next step is going to be moving to Guice.
Jerry
On 10/13/2019 10:11 PM, Tellier Benoit wrote:
Hi Jerry,
Globally, we expect users to rely on extensions mechanisms James
provides, and not on DB schemas (that might change in the future!)
I would advise you to rely on MailboxListeners (that receives events
from users mailboxes)
The Added event is here the one that interest you. You can rely on the
"MessageId" property to correlate with your bookmark content and thus
being able to update it.
MailboxListener is only supported by Guice...
Best regards,
Benoit Tellier
On 12/10/2019 11:50, Jerry Malcolm wrote:
I need a little more education... I understand that fundamentally IMAP
and all mail storage is pretty much 'top down'. The user starts at the
top folder and drills down through sub folders until they locate the
email in question. And there are search engines that basically do the
same drilling down and find matching emails. Let's say I need to return
to a specific email often, so I set up an external 'bookmark' that
references the account and folder path of this email, and via IMAP I can
easily access this email at any time. No problems whatsoever with
that. The problem happens when the user decides to clean out a folder
and move the mail to an "Archived Mail - 2019" folder. From what I can
tell, it's a new sunrise for that email in its new location with no way
to back link it to my previously bookmarked folderPath. Is that
correct? Is there any unique database information for that mail record
that I could save and subsequently use to find it again once it has
changed folders? I'm simply looking for a guaranteed unique UID that
would allow me to keep track of an email as long as it is somewhere in
the database. This doesn't have to be something exposed in IMAP. I
have no problem going straight to the database and finding a record with
this 'possible' UID if that is necessary in order to update my
'bookmark'. Is there any UID already available that persists for the
life of the email I've totally missed? Or is this just something I need
to live with for now?
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
