Skip Menu |

This queue is for tickets about the Mail-Box CPAN distribution.

Report information
The Basics
Id: 132823
Status: resolved
Priority: 0/
Queue: Mail-Box

People
Owner: MARKOV [...] cpan.org
Requestors: alexander.adolf [...] condition-alpha.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: [feature suggestion] access messages by filename
Date: Mon, 15 Jun 2020 18:26:30 +0200
To: bug-Mail-Box [...] rt.cpan.org
From: Alexander Adolf <alexander.adolf [...] condition-alpha.com>
Distribution name and version: Mail-Box-3.008 Perl version: 5.30.2 Operating System: macOS 10.15.4 Hello Mark, I am using your Mail::* packages for setting up an email solution based on notmuch, and emacs. The perl scripts are for moving messages around, and physically deleting them (both of which notmuch doesn't do). Your Mail::* packages are genius! Thanks so much for making them available! In making my scripts, I have found that some S/MIME messages do not have a message id header, because that is contained in an encrypted mime part. Notmuch generates its own message ids for these, in order to be able to refer to them within notmuch. In my script, I am acting on lists of message ids resulting from notmuch queries. When I do a Mail::Box::find, I will of course not find the encrypted messages for which notmuch has devised synthetic message ids. As an alternative to message ids, notmuch can also deliver lists of file names as its query results. So I thought I could probably slap up something using Mail::Box::messages(), and compare against Mail::Box::Dir::Message::filename() (I'm using Maildir) in the filter function. While that would do the job, it did seem somewhat inefficient to me to iterate over all messages in the mailbox for accessing a given message. I thought that it could be much more efficient, if it could be part of the public Mail::Box::Dir interface. Given a file name, I guess all you would need to do is check whether a message with that file name exists in the cur, new, or tmp folder (in the Maildir case). If it exists, return it as a message object, else return undef. Looking forward to your thoughts, --alexander
On Mon Jun 15 12:28:40 2020, alexander.adolf@condition-alpha.com wrote: Show quoted text
> [...] I thought that it could be much more efficient, if it could be > part of the public Mail::Box::Dir interface. Given a file name, I guess > all you would need to do is check whether a message with that file name > exists in the cur, new, or tmp folder (in the Maildir case). If it > exists, return it as a message object, else return undef.
Convincing story. Opening "dir" folders is very lazy: the messages do not get opened at all unless needed. So, I think all you need is this: --- a/lib/Mail/Box/Dir.pm +++ b/lib/Mail/Box/Dir.pm @@ -166,7 +166,19 @@ sub folderToDirectory($$) $dir; } -#------------------------------------------- +sub storeMessage($) +{ my ($self, $message) = @_; + $self->SUPER::storeMessage($message); + my $fn = $message->filename or return $message; + $self->{MBD_by_fn}{$fn} = $message; +} + +=method messageInFile $filename +Returns the folder message which is found the indicated C<filename>. This +may be useful when some external tool reports filename to be opened. +=cut + +sub messageInFile($) { $_[0]->{MBD_by_fn}{$_[1]} } =method readMessageFilenames $directory
No bugfixes or other contributions for months, so now released as only change in 3.009