I agree organizing weddings is a hell of a mess, having been recently gone through this process myself...
> (I have filmed over 600 weddings across nearly 18 years... so > the maildb is huge. Searching is not trivial) Well, scanning search sounds like a hell yes. However hopefully some other options are available. James 3.x releases includes some advanced search engines that should be relyable and efficient up to a few million emails. Lucene is the de-facto indexing choice we made for JPA Guice. It's also available in Spring (indexer.xml file). Searching large DBs should not be a problem. > I figure I could just do > a search on the entire maildb each time looking for any mail that > matches any of 20+ email addresses. I'd argue you'll end up with a functional issue: what if one the previous bride gets a mum and emails you for marrying her daughter? :-) You could: - assign a custom mail header / custom flags upon the mailet pipeline for a mail you correlated with a wedding - Rely on multi-mailbox search using aforementioned (not yet implemented) RFC-6237. Cheers, Benoit On 15/10/2019 10:52, Jerry Malcolm wrote: > Hi Benoit, > > When I'm talking with my own software clients, my standard line to the > client is "don't tell me your recommended solution.... start with what > the problem is that you want to solve, and we'll work together on the > best solution." And here I find myself telling you what I think the > solution is when there might be a totally different and much better way > already architected into James to solve the problem.... So I'm hitting > 'reset'. Here's the actual problem I want to solve. > > Totally separate from my software development and hosting businesses, I > also have a wedding and event video business. When I book a wedding, I > start having to deal with bride, groom, planner, Mother of Bride, Mother > of Groom, etc. etc. Over the months before and after the wedding, I get > a bunch of emails from each of these people. And to make matters worse, > after the wedding, the bride often changes her email address if she > changes her last name. In my CRM I have an entry for the "Smith/Jones > Wedding". I have an "email history" log that is crucial to keeping up > with all correspondence between me, my employees, and about 20 different > email addresses for everyone I'm dealing with related to this wedding. > I have mailets that monitor all outbound and inbound mail. If I find > one to/from any of the email addresses I have on record associated with > this wedding, I log an entry in the CRM email history log for this > wedding. I want to be able to retrieve and open the email directly from > the CRM log. My current implementation works fine until I need to clean > up mail folders and archive older mail which loses the links to be able > to open those emails since the paths change. I figure I could just do > a search on the entire maildb each time looking for any mail that > matches any of 20+ email addresses. But that seems to be a performance > nightmare (I have filmed over 600 weddings across nearly 18 years... so > the maildb is huge. Searching is not trivial). So I keep a separate > log and 'try' to keep the entries pointed to the mail's location in > james so I can access the email item on demand. > > So if there's a better way to create 'groups' for all mail in the entire > email account for 20+ random email addresses and get a list > (efficiently) of all matching to/from emails, I'm ready to learn a > different way. > > Thx as always. > > Jerry > > On 10/14/2019 10:09 PM, Tellier Benoit wrote: >> 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 >> > > --------------------------------------------------------------------- > 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
