Re: Email::FolderType::MH
On Wed, Jun 25, 2014 at 09:50:01PM -0700, Geoffrey Leach said: Before I try to produce one, can anyone tell me why Email::FolderType::MH does not exist? In particular, was there a problem that seemed insurmountable? Err, it does and has done for 9 years. http://search.cpan.org/~rjbs/Email-FolderType-0.814/lib/Email/FolderType/MH.pm Did you mean something else other than MH?
Re: Email::Classifier: not dead yet
On Mon, Dec 01, 2008 at 07:15:20PM -0500, Ricardo SIGNES said: I may sit on it for another week or so, but unless I get some feedback on the order of no, stop, this is crazy! I am going to release it and start using it for things. Your input is hereby requested! This is more a point of philosophy and should probably be rephrased as a question but - the original goal of the Email project when I helped start it was to be as fast and lightweight as possible with as few non-core dependencies as could possibly be gotten away with[*]. As far as I can tell from a quick glance Classifier could be trivially rewritten to use absolutely no non-core dependencies - I know Moose is the flavour du jour but I'm still sad to the original goal abandoned. But hey, this is your baby now (and has been for a long time) so I suppose I have no right to grouse. Simon [*] Email::Store being the glaring counterexample and even that 'only' used 4 non-core, non-Email modules
Re: Email::Store is dead! Long live Email::Store!
On Tue, Sep 18, 2007 at 07:40:04PM -0500, Karen Cravens said: So, uh, anyway. Where were we? Oh yeah. How 'bout that Email::Store? (Email::Archive?) There are a bunch of lessons that I learnt from working on Email::Store (I wasn't the original author) that I wanted to correct with a putative rewrite that I never got round to. 1) The package based design This was partly fallout of being based on Class::DBI but I diskliked everything being based on Package variables so use Email::Store 'dbi:mysql:mailstore'; Email::Store-setup; # Do this once Email::Store::Mail-store( $rfc822 ); Email::Store::Mail-retrieve( $msgid ); what I would have preferred was my $store = Email::Store-new(%opts); my $mess = $store-message($id); my $top = $mess-thread-top; which would have made $store2-add($mess); possible. 2) No pluggable backend Email::Store was tied closely to Class::DBI which was best of breed at the time. It would have been nice if it could have pluggable backends so that you could have used whatever storage engine you wanted - Class::DBI, DBIx::Class, Data::ObjectDriver even IMAP or a maildir. To be fair, I'm not exactly sure how this would work - some sort of declarative schema like Jifty::DBI maybe. 3) Always keep a pristine copy of the message around Err, that's pretty much it. It may mean that you bloat you index size but I think it's worth it in the long run. It means you can install plugins (if yours is going to be plugin based) or upgrade the system and add new functionality that you no is going to work and you never have to reindex your dataset. 4) That said, convert everything to UTF-8 Apart from the pristine copy (which should be outputted in ASCII) try and do everything in UTF8. It just makes things easier. 5) Watch your timezones. Another tricky problem that it's always best to be thinking of from the start rather than trying to retrofit. 6) Think of conversations rather than emails It might be worth architecting it as a series of conversations rather than being email specific. That way later you could add in UseNet for a Deja News style affair (ok so UseNet is very much like email but there are differences) and maybe even more exotic things like blog posts (which let's face it, with comments, merely an email thread), IM conversations or SMS. Especially given your webboard-meets-mailing-list aspirations that might be especially useful. So onto that (the forum/ml idea). I like the idea and it's something I've toyed around with over the years - give the people who want forums what they want and the people who want a mailing list what *they* want and they can be blisfully ignorant of each other (Yahoo! Groups sort of does this as far as I know). I think it may be worth keeping the three pieces loosely coupled i.e Mailing List Manager (like MailMan, Majordomo, Siesta or Sympa), Archive (Email::Store or Email::Archive) and web front end (e.g sort of Buscador or to an even lesser extent Pipermail, MHonArc or Mariachi). I'm interested to see your progress and design ideas. Simon
Re: Email::Store is dead! Long live Email::Store!
On Mon, Sep 17, 2007 at 03:18:08PM -0700, Steve Atkins said: I'd like a perl-based mailing list manager myself Myself and a couple of other people wrote a Perl based MLM called Siesta about 5 years ago. We did it for four reasons 1) To shut people up who said that there was no Perl based MLM 2) It allowed per user Reply-To munging settings thus shutting up even more whiners 3) Mailman can be kind of sucky, especially if you want to extend it. Siesta was plugin based which kept things clean and simple. 4) We were employment-challenged at the time and bored. Article here http://www.perl.com/pub/a/2004/02/05/siesta.html Code on CPAN. It should be noted that the the latest changes to various module in the Email:: namespace break it. I don't have time to debug so I just downgraded instead. It's a bit rough around the edges and it has no web frontend (I hate doing web stuff) although there was a prototype that got knocked up in PHP (long story) but I've been using it for 4 years to run various mailing lists and it works fine and there's some neat ideas - I particularly like, for some reason, that when you create a backup using the command line tool it generates a shell script which will reimport everything again using the command line tool. Anyway, that's just a data point but I thought I'd mention it. As it turns out that, despite what most people say, even if there *is* a Perl MLM they probably won't use it - see also: Sympa. Simon
Re: Email::Store is dead! Long live Email::Store!
On Fri, Sep 14, 2007 at 05:00:51PM -0400, Christopher Nehren said: I've been working on cobbling together a modern mailing list manager written in Perl (Saddlebags), because I find it absolutely unacceptable that things like the dbic list are running on mailman. As a part of this, the subject of storing emails in databases came up. Obviously, we turned to Email::Store. I'm all in favour of rewriting Email::Store - I've never got round to doing all the work I needed to do rewriting it. Everytime I sit down to do it something else gets in the way. As for Perl MLMs - have you looked at Siesta? It's a bit rough and ready in some places but I've been running mailing lists off it for years.
line feeds in Email::Simple
At the moment when parsing a mail we make a note of the end of the line marker and then use that to reconstruct the mail when the as_string() method is called. However, as was pointed out to me rf2822 says A line is a serie ofcharacters that is delimited with the two characters carriage-return and line-feed; See also http://qix.it/~ludoo/archive/2004/07/line_endings.html So we should probably have a an option some how (either passed into new or $Email::Simple::EOL_MODE) which dictates whether we want 1) Force DOS line feeds (the default) 2) Force Unix line feeds (technically not a rfc2822 mail) 3) Force Mac line feeds (see above) 4) Whatever was in the mail already (current default) Simon
Re: (Ab)using Email::Store::Entity
On Sat, May 28, 2005 at 03:43:46AM -, Karen J. Cravens said:
Does anybody see anything egregiously stupid about doing this? I mean,
besides the fact that I'm going to have to deal with custom versions of
core (to Email::Store, anyhow) packages, that is.
Sorry it's taken so long to get back to you - I've been absolutely
swamped.
If I'm reading your right (and that's not guaranteed since I'm coming
down with a post heavy week and end of project cold) then you just want
to correlate entities differently.
You could always create a ne wplugin called Email::Store::SimpleEntity
and then exclude the original Entity plugin from being imported using
use Email::Store { except = [ Email::Store::Entity ] }, $dsn;
Let me know if that's not what you meant.
Simon
[cpan #12920] Some extensions for Email::Folder::Maildir
This forwarded from brian d foy - I think I'm against the proposal but I
need a bit of time to nail down why precisely.
Brian D Foy said:
I was playing with Email::Folder::Maildir, but wanted to move around in
the message queue. I added a lot to the package and here it is. I'd
really like to see the same API available to all subclasses of
Email::Folder::Reader, where appropriate.
BEGIN {
package Email::Folder::Maildir;
sub count {
$_[0]-{_messages} || $_[0]-_what_is_there;
scalar @{ $_[0]-{_messages} };
}
sub new { shift-SUPER::new( @_ )-init }
sub init
{
$_[0]-_what_is_there;
$_[0]-{_cursor} = -1; # next_message starts at 0;
$_[0]
}
sub messages { $_[0]-{_messages}}
sub message_total{ $#{ $_[0]-messages } + 1 }
sub cursor { $_[0]-{_cursor} += $_[1] }
sub current_message { $_[0]-get_message( $_[0]-cursor ) }
sub previous_message { $_[0]-get_message( $_[0]-cursor( -1 ) ) }
sub next_message { $_[0]-get_message( $_[0]-cursor( +1 ) ) }
sub message_file
{
abs( $_[1] ) = $_[0]-message_total ?
$_[0]-{_messages}[ $_[1] ] : ()
}
sub get_message
{
my $self = shift;
my $num = shift;
my $file = $self-message_file( $num );
open my($fh), $file or carp Couldn't open file $file: $!;
my $message = join '', $fh;
}
}
Re: Accessing via POP3 and extracting attachments
On Mon, Feb 14, 2005 at 12:56:52PM +, Jos? Castro said: Hi, guys. I'm about to code something that should access a mail account via POP3, extract the new emails, filter only the ones with a specific sender/subject, check for attachments and, if existing, save them to disk and do stuff with them. Seems fine although, if you wnated to drink the Email::* kool-aid you could write Email::Folder::POP3 and Email::FolderType::POP3 (and Email::Delete::POP3 :) I have to admit I found problems with Email::MIME and switched to MIME::Parser (hopefully temporarily) in Email::Store::Attachment http://siesta.unixbeard.net/svn/trunk/Email-Store/lib/Email/Store/Attachment.pm
