Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

rjbs (4671)

rjbs
  (email not shown publicly)
http://rjbs.manxome.org/
AOL IM: RicardoJBSignes (Add Buddy, Send Message)
Yahoo! ID: RicardoSignes (Add User, Send Message)

I'm a Perl coder living in Bethlehem, PA and working Philadelphia. I'm a philosopher and theologan by training, but I was shocked to learn upon my graduation that these skills don't have many associated careers. Now I write code.

Journal of rjbs (4671)

Wednesday May 30, 2007
08:25 AM

toward email::simple 2.0

[ #33375 ]

First:

In case you're subscribed, note that the pep-checkins is currently busted. I haven't even looked into it, yet. We moved PEP svn from a standalone machine to a Solaris zone recently, and I probably broke something stupid.

I bring this up because I know that it means none of you have probably seen the Email::Simple checkins I made yesterday. I'm trying to get ready to release
Email::Simple 2.000. It's going to be a great release, I think. I'm not
trying to do the crazy "not-backwards-compatible changes at major version
number!" thing. Instead, I'm trying to document and standardize more of the
interface. My mantra for the 2.x series of Email::Simple is "better interface
standardization." I want it to do roughly the same amount of stuff, with
roughly the same performance. I just want it to be clearer how one can
subclass Email::Simple, and I want to refactor, document, and improve the
usability of the core features of Email::Simple. (This will probably include a rewrite of the Email::Simple<->Data::Message relationship.)

Here's a summary of things I checked in last night:

  • better documentation for the Email::Simple::Header object
  • provide a means to request a different header class
  • public interface for header folding
  • documented how options are passed to Email::Simple constructor
  • add options to as_string, namely options to alter header folding
  • add methods that return default values of various options
  • some performance improvements

These changes are mostly here to make it easier to subclass Email::Simple's
behavior. In almost every case, I want the answer to "how do I change
Email::Simple's" behavior to be "subclass" or (later) "use a plugin." Since
some features are really very fundamental core features, though, they seemed
like a good place to demonstrate my intentions.

I'm going to release this as a _x release, soon. Let us know if you have thoughts on these plans or changes: PEP Wiki

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I think we're going to need an Email::Simple::Simple soon. Or maybe start again on yet another namespace.
    • Hi Simon,

      Funny - but not practical or fair.

      The Email::Simple API (and code!) has a lot of old suck in it - even if less than the other email modules ...

      Richardo has done a great job cleaning up the API and the code to be simpler and easier to use in Real Applications.

        - ask
      --

      -- ask bjoern hansen [askbjoernhansen.com], !try; do();