Hi Jerry, First I'd begin with a quick thought that might save you some consequent development and configuration time.
What exactly are the features of your bookmark? Because it sounds to me search and custom flags might be enough. RFC-6237 "IMAP4 Multimailbox SEARCH Extension" might also be a must read for your feature. (not yet implemented in James but should be easy) Such an approach would avoid external state tracking (brittle) at the cost of a simple IMAP extension development. If you don't have new features in your "bookmark" application, then this might be the "most standard way to go". That being said, I'll answer your other questions: 1) A bit of warning first: ToRecipientFolder is deprecated. The way to do that is combining WithStorageDirective and LocalDelivery mailets. 2) Yes, a sample implementation is "random UUID" However some little dev might be required for JPA to persist messageId (I just looked through the code) We wrote this tutorial http://james.apache.org/howTo/custom-listeners.html for helping users and devs write their own listener, this might be a good starting point for you. > It looks like my next step is going to be moving to Guice. Yeah!!! Cheers, Benoit On 15/10/2019 05:20, Jerry Malcolm wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
