in reply to RFC: Net::SMTP::Pipelining

I haven't tested your code just yet, but I mean to get around to it. I should have a chance today or tomorrow.

I do have a comment on the name. I think Net::SMTP::Pipelining is fine. I know the protocol RFCs usually show their commands in uppercase, but unless it's actually an acronym (like SMTP) I personally wouldn't expect a module name to be all capitals.

This is an interesting problem you're solving. It's good to see it as a module in its own right. It'd be even more interesting to me if the functionality was worked into Net::SMTP::TLS which is my mail-sending module of choice. Having pipelining along with encryption and SMTP authentication would be really nice. I'm sure others would like it worked into Net::SMTP since that's a commonly used module.

Is the end plan to have yet another mail sending module, or are you proving the concept for adding this feature elsewhere? Keeping it separate is good. Getting this functionality into modules with other features would make those other modules that much better, though. The folks who maintain the other modules would probably be happy to help implement this in them, too. I know I'd be happy to help put it into Net::SMTP::TLS as a user of that module.

Replies are listed 'Best First'.
Re^2: RFC: Net::SMTP::Pipelining
by tirwhan (Abbot) on Feb 18, 2009 at 17:23 UTC
    Thank you for your comments!
    It'd be even more interesting to me if the functionality was worked into Net::SMTP::TLS

    One of the reason I chose this particular design (inheriting from Net::SMTP rather than using it within the module) is that I wanted to be able to mix it with other modules that also inherit from Net::SMTP (like Net::SMTP_auth and Net::SMTP::SSL). So version 0.0.2 will have a method ("extend_esmtp_pipelining" or somesuch) to which you can pass an object in a Net::SMTP (sub-)class which will then add the pipelining capability (I haven't actually thought about how to implement this 100% but I'm sure it can be done).

    Unfortunately, this does not help Net::SMTP::TLS, because that module does not inherit from Net::SMTP, but rather reimplements it. So unless AWESTHOLM wants his module to depend on Net::SMTP::Pipelining (which I doubt he will want to do, the whole point of the existence of Net::SMTP::TLS seems to be the desire to be free of a dependency on Net::SMTP) there will have to be some porting involved I think. I'll be happy to do that porting if there are people who'd want such a thing (and your question shows there are :-), but I'd rather have the code living in it's own module for a few weeks at least, to see whether that shakes out any bugs. I also wish there'd be a way to avoid such porting (duplicate code bad), but having looked at Net::SMTP::TLS a little just now I don't think it could be avoided.

    I'm sure others would like it worked into Net::SMTP since that's a commonly used module.

    If that is indeed the case I'll be happy to do so. That was my initial plan when I first approached this problem, but I quickly found that the problem was sufficiently intricate, and the actual process of sending an email and reporting results sufficiently different, to have the code for it live in a separate module initially. Net::SMTP is in core (which has a reputation for disdaining new features) and I wouldn't want to plunk my (possibly buggy) code on millions of unsuspecting users. Releasing it as stand-alone seems the best way to beta-test. If there is indeed popular demand to having this feature in core I'll happily deprecate this module and move the code over.


    All dogma is stupid.
[reply]
[d/l]
[select]
      Inheriting from it is of course the next best thing. I probably should have mentioned that straightaway. People who want pipelining enough who are currently using Net::SMTP will no doubt be happy that only minor changes to their code are necessary.

      As a matter of fact, from a cursory inspection it seems it shouldn't take me much effort to clone what you have here and have it inherit from Net::SMTP::TLS instead. I'd like to take a crack at that sometime soon if I have your blessing to do so.

      Now that I think about it, having Net::SMTP::Pipelining and Net::SMTP::TLS::Pipelining (or should that be Net::SMTP::Pipelining::TLS?) wouldn't be such a bad idea. It is a great and useful feature, but it's not necessary for everyone. Keeping it out of the API of existing modules might be better in the long run. Now I'm torn.

[reply]
        I'd like to take a crack at that sometime soon if I have your blessing to do so.

        Absolutely, go for it. I still feel kinda queasy about the idea of duplicating code in two different modules. So maybe (thinking out loud here) it would be better to build a switch into Net::SMTP::Pipelining that makes it use Net::SMTP::TLS as the base class when it's called as Net::SMTP::TLS::Pipelining->new(). That would be messy internally but avoid duplication.

        And I'm not entirely sure that extending the incompatible API of Net::SMTP::TLS even further is the right way to go. It seems to me that a better way (in the long run) would be to create modules which add the extra functionality of Net::SMTP::TLS to a subclass of Net::SMTP (e.g. creating Net::SMTP_TLS and improving Net::SMTP_auth). Given that Net::SMTP::TLS does no longer seem to be very actively maintained, that way we could have all SMTP functionality that people want collected under one namespace and core module. But whatever rocks your boat :-).

        If you do create another module I'd call it Net::SMTP::TLS::Pipelining (not NS::Pipelining::TLS) though. NS::TLS is distinct from the other NS modules, so keeping stuff that's specific to it under it's namespace makes sense to me.


        All dogma is stupid.
[reply]
[d/l]

In Section Meditations